[PATCH] btrfs: no need to check return value of debugfs_create functions

[PATCH] btrfs: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Chris Mason <clm@fb.com>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/btrfs/sysfs.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

Meta-comment, why is there a btrfs debugfs directory at all?  All you
have here is a single "test" file that doesn't do anything except expose
a variable that never changes.  What is this directory and single file
for?  Can I just delete the whole thing?


diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 5a5930e3d32b..38cbb2076d6c 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -905,12 +905,10 @@ void btrfs_sysfs_feature_update(struct btrfs_fs_info *fs_info,
 	ret = sysfs_create_group(fsid_kobj, &btrfs_feature_attr_group);
 }
 
-static int btrfs_init_debugfs(void)
+static void btrfs_init_debugfs(void)
 {
 #ifdef CONFIG_DEBUG_FS
 	btrfs_debugfs_root_dentry = debugfs_create_dir("btrfs", NULL);
-	if (!btrfs_debugfs_root_dentry)
-		return -ENOMEM;
 
 	/*
 	 * Example code, how to export data through debugfs.
@@ -924,7 +922,6 @@ static int btrfs_init_debugfs(void)
 #endif
 
 #endif
-	return 0;
 }
 
 int __init btrfs_init_sysfs(void)
@@ -935,9 +932,7 @@ int __init btrfs_init_sysfs(void)
 	if (!btrfs_kset)
 		return -ENOMEM;
 
-	ret = btrfs_init_debugfs();
-	if (ret)
-		goto out1;
+	btrfs_init_debugfs();
 
 	init_feature_attrs();
 	ret = sysfs_create_group(&btrfs_kset->kobj, &btrfs_feature_attr_group);
@@ -954,7 +949,6 @@ int __init btrfs_init_sysfs(void)
 	sysfs_remove_group(&btrfs_kset->kobj, &btrfs_feature_attr_group);
 out2:
 	debugfs_remove_recursive(btrfs_debugfs_root_dentry);
-out1:
 	kset_unregister(btrfs_kset);
 
 	return ret;
-- 
2.20.1

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[Nikolay Borisov]

On 4.01.19 г. 15:25 ч., Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
> 
> Cc: Chris Mason <clm@fb.com>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: David Sterba <dsterba@suse.com>
> Cc: linux-btrfs@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  fs/btrfs/sysfs.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> Meta-comment, why is there a btrfs debugfs directory at all?  All you
> have here is a single "test" file that doesn't do anything except expose
> a variable that never changes.  What is this directory and single file
> for?  Can I just delete the whole thing?
> 

git blame is your friend - 1bae30982bc8 ("btrfs: add simple debugfs
interface")


Apparently David had an idea to do something but it never materialized,
imo the debugfs bits could be removed from sysfs.c

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

On Fri, Jan 04, 2019 at 03:36:59PM +0200, Nikolay Borisov wrote:
> 
> 
> On 4.01.19 г. 15:25 ч., Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Cc: Chris Mason <clm@fb.com>
> > Cc: Josef Bacik <josef@toxicpanda.com>
> > Cc: David Sterba <dsterba@suse.com>
> > Cc: linux-btrfs@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  fs/btrfs/sysfs.c | 10 ++--------
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> > 
> > Meta-comment, why is there a btrfs debugfs directory at all?  All you
> > have here is a single "test" file that doesn't do anything except expose
> > a variable that never changes.  What is this directory and single file
> > for?  Can I just delete the whole thing?
> > 
> 
> git blame is your friend - 1bae30982bc8 ("btrfs: add simple debugfs
> interface")
> 
> 
> Apparently David had an idea to do something but it never materialized,
> imo the debugfs bits could be removed from sysfs.c

Ok, I'll gladly delete all of the code if the maintainers will accept
such a patch.

thanks,

greg k-h

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[David Sterba]

On Fri, Jan 04, 2019 at 02:25:20PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
> 
> Cc: Chris Mason <clm@fb.com>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: David Sterba <dsterba@suse.com>
> Cc: linux-btrfs@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  fs/btrfs/sysfs.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> Meta-comment, why is there a btrfs debugfs directory at all?  All you
> have here is a single "test" file that doesn't do anything except expose
> a variable that never changes.  What is this directory and single file
> for?  Can I just delete the whole thing?

As explained in the commit that introduces the function
(1bae30982bc86ab66d61ccb):

  Help during debugging to export various interesting infromation and
  tunables without the need of extra mount options or ioctls.

  Usage:
  * declare your variable in sysfs.h, and include where you need it
  * define the variable in sysfs.c and make it visible via
    debugfs_create_TYPE

  Depends on CONFIG_DEBUG_FS.

It's there for developers, so don't delete it. Which also means the
error code should be handled and not ignored.

I can enhance the comment so it's explained in-place and not too
tempting to remove it. This is not the first time somebody wants to
remove it
(https://lore.kernel.org/linux-btrfs/d6715b5b-0aa3-3032-43c6-eccd907a60b8@redhat.com/),

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

On Fri, Jan 04, 2019 at 02:44:49PM +0100, David Sterba wrote:
> On Fri, Jan 04, 2019 at 02:25:20PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Cc: Chris Mason <clm@fb.com>
> > Cc: Josef Bacik <josef@toxicpanda.com>
> > Cc: David Sterba <dsterba@suse.com>
> > Cc: linux-btrfs@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  fs/btrfs/sysfs.c | 10 ++--------
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> > 
> > Meta-comment, why is there a btrfs debugfs directory at all?  All you
> > have here is a single "test" file that doesn't do anything except expose
> > a variable that never changes.  What is this directory and single file
> > for?  Can I just delete the whole thing?
> 
> As explained in the commit that introduces the function
> (1bae30982bc86ab66d61ccb):
> 
>   Help during debugging to export various interesting infromation and
>   tunables without the need of extra mount options or ioctls.
> 
>   Usage:
>   * declare your variable in sysfs.h, and include where you need it
>   * define the variable in sysfs.c and make it visible via
>     debugfs_create_TYPE
> 
>   Depends on CONFIG_DEBUG_FS.
> 
> It's there for developers, so don't delete it. Which also means the
> error code should be handled and not ignored.

If no one has used it, why keep it?

Anyway, if you want it there, that's fine, but no, the error message can
be ignored.  You should never have a different code flow if a debugfs
call fails or not.  So the patch I posted here is still correct and
should be applied.

> I can enhance the comment so it's explained in-place and not too
> tempting to remove it. This is not the first time somebody wants to
> remove it
> (https://lore.kernel.org/linux-btrfs/d6715b5b-0aa3-3032-43c6-eccd907a60b8@redhat.com/),

If it keeps wanting to get removed, that's a big hint maybe you should :)

thanks,

greg k-h

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[David Sterba]

On Mon, Jan 14, 2019 at 03:21:04PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 04, 2019 at 02:44:49PM +0100, David Sterba wrote:
> > On Fri, Jan 04, 2019 at 02:25:20PM +0100, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
> > > return value.  The function can work or not, but the code logic should
> > > never do something different based on this.
> > > 
> > > Cc: Chris Mason <clm@fb.com>
> > > Cc: Josef Bacik <josef@toxicpanda.com>
> > > Cc: David Sterba <dsterba@suse.com>
> > > Cc: linux-btrfs@vger.kernel.org
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > ---
> > >  fs/btrfs/sysfs.c | 10 ++--------
> > >  1 file changed, 2 insertions(+), 8 deletions(-)
> > > 
> > > Meta-comment, why is there a btrfs debugfs directory at all?  All you
> > > have here is a single "test" file that doesn't do anything except expose
> > > a variable that never changes.  What is this directory and single file
> > > for?  Can I just delete the whole thing?
> > 
> > As explained in the commit that introduces the function
> > (1bae30982bc86ab66d61ccb):
> > 
> >   Help during debugging to export various interesting infromation and
> >   tunables without the need of extra mount options or ioctls.
> > 
> >   Usage:
> >   * declare your variable in sysfs.h, and include where you need it
> >   * define the variable in sysfs.c and make it visible via
> >     debugfs_create_TYPE
> > 
> >   Depends on CONFIG_DEBUG_FS.
> > 
> > It's there for developers, so don't delete it. Which also means the
> > error code should be handled and not ignored.
> 
> If no one has used it, why keep it?

That no one can tell for sure, we don't get notified. I know that
implementing the debugfs support was not all trivial and saved time.
If this savs time to other developers, why delete it?

> Anyway, if you want it there, that's fine, but no, the error message can
> be ignored.  You should never have a different code flow if a debugfs
> call fails or not.  So the patch I posted here is still correct and
> should be applied.

I disagree with that. The usecase is for devleopers, who intentionally
add own debugging information. It does not mean the code changes gets
committed in the end, but the debugfs infrastructure is used and should
work reliably at this point. This means that either the data get
exported or there's an early exit when something goes wrong. Silent
failure in this case can waste hours of testing or debugging.

I fail to see your logic to never rely on debugfs calls success/failure.
Debugfs is a tool like any other, with narrow group of users and
usecases but can be valuable.

If you need to extend return values or do other cleanups, then fine, but
I'm not going to apply the patch in its current form as it would harm my
own usecase, sorry.

> > I can enhance the comment so it's explained in-place and not too
> > tempting to remove it. This is not the first time somebody wants to
> > remove it
> > (https://lore.kernel.org/linux-btrfs/d6715b5b-0aa3-3032-43c6-eccd907a60b8@redhat.com/),
> 
> If it keeps wanting to get removed, that's a big hint maybe you should :)

If there's a good explanation why it should be removed, then yes. If
there's a reason to keep it, then no. So far I've seen drive-by attempts
to remove some seemingly unused code by people who don't work in the
area of the subsystem and may not understand its purpose.

Re: [PATCH] btrfs: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

On Thu, Jan 24, 2019 at 05:36:01PM +0100, David Sterba wrote:
> On Mon, Jan 14, 2019 at 03:21:04PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Jan 04, 2019 at 02:44:49PM +0100, David Sterba wrote:
> > > On Fri, Jan 04, 2019 at 02:25:20PM +0100, Greg Kroah-Hartman wrote:
> > > > When calling debugfs functions, there is no need to ever check the
> > > > return value.  The function can work or not, but the code logic should
> > > > never do something different based on this.
> > > > 
> > > > Cc: Chris Mason <clm@fb.com>
> > > > Cc: Josef Bacik <josef@toxicpanda.com>
> > > > Cc: David Sterba <dsterba@suse.com>
> > > > Cc: linux-btrfs@vger.kernel.org
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > ---
> > > >  fs/btrfs/sysfs.c | 10 ++--------
> > > >  1 file changed, 2 insertions(+), 8 deletions(-)
> > > > 
> > > > Meta-comment, why is there a btrfs debugfs directory at all?  All you
> > > > have here is a single "test" file that doesn't do anything except expose
> > > > a variable that never changes.  What is this directory and single file
> > > > for?  Can I just delete the whole thing?
> > > 
> > > As explained in the commit that introduces the function
> > > (1bae30982bc86ab66d61ccb):
> > > 
> > >   Help during debugging to export various interesting infromation and
> > >   tunables without the need of extra mount options or ioctls.
> > > 
> > >   Usage:
> > >   * declare your variable in sysfs.h, and include where you need it
> > >   * define the variable in sysfs.c and make it visible via
> > >     debugfs_create_TYPE
> > > 
> > >   Depends on CONFIG_DEBUG_FS.
> > > 
> > > It's there for developers, so don't delete it. Which also means the
> > > error code should be handled and not ignored.
> > 
> > If no one has used it, why keep it?
> 
> That no one can tell for sure, we don't get notified. I know that
> implementing the debugfs support was not all trivial and saved time.
> If this savs time to other developers, why delete it?

Because normally, we do not just "leave code around" in the kernel for
someone else to pick up at some unknown time in the future because they
might just happen to need it.

'git revert' is a wonderful thing, and simple, if people want to add
stuff back.

> > Anyway, if you want it there, that's fine, but no, the error message can
> > be ignored.  You should never have a different code flow if a debugfs
> > call fails or not.  So the patch I posted here is still correct and
> > should be applied.
> 
> I disagree with that. The usecase is for devleopers, who intentionally
> add own debugging information. It does not mean the code changes gets
> committed in the end, but the debugfs infrastructure is used and should
> work reliably at this point. This means that either the data get
> exported or there's an early exit when something goes wrong. Silent
> failure in this case can waste hours of testing or debugging.

There is no debugfs files or interaction at all here in btrfs.  So why
are you trying to create a directory that is never used, and if you
happen to have that fail, abort all of btrfs?

You should never have any "real" kernel code logic affected by what
debugfs happens to do, or not do.  It's a debugging interface, no one
should ever rely on it for a system to work properly.

And that's the main cleanup I did here, just call debugfs to create the
directory, and move on.  No need to worry if it worked or not (hint, it
almost allways will unless the system is out of memory, and at that
time, you have bigger problems).  The goal is to make it simpler to use
debugfs, and again, never have any problems that might happen in it
affect anything else in the kernel.

> I fail to see your logic to never rely on debugfs calls success/failure.
> Debugfs is a tool like any other, with narrow group of users and
> usecases but can be valuable.

Sure, but again, do not keep your system from working because debugfs
did something odd.

> If you need to extend return values or do other cleanups, then fine, but
> I'm not going to apply the patch in its current form as it would harm my
> own usecase, sorry.

What usecase is affected right now?  There is no usecase for this
directory at the moment :)

> > > I can enhance the comment so it's explained in-place and not too
> > > tempting to remove it. This is not the first time somebody wants to
> > > remove it
> > > (https://lore.kernel.org/linux-btrfs/d6715b5b-0aa3-3032-43c6-eccd907a60b8@redhat.com/),
> > 
> > If it keeps wanting to get removed, that's a big hint maybe you should :)
> 
> If there's a good explanation why it should be removed, then yes. If
> there's a reason to keep it, then no. So far I've seen drive-by attempts
> to remove some seemingly unused code by people who don't work in the
> area of the subsystem and may not understand its purpose.

We remove code that never gets used all over the place.  If you do use
it, great, put some users in the tree.  If you do not, then drop it and
it is simple to revert at some point in the future if you need it again.

thanks,

greg k-h