linux-kernel - Re: [PATCH] debugfs: Document that debugfs_create functions need not be error checked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Yhi1PieJPFPzjIdg@kroah.com>
Date:   Fri, 25 Feb 2022 11:53:50 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     Douglas Anderson <dianders@...omium.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] debugfs: Document that debugfs_create functions need not
 be error checked

On Wed, Feb 23, 2022 at 09:49:15AM +0100, Javier Martinez Canillas wrote:
> Hello Doug,
> 
> On 2/23/22 00:46, Douglas Anderson wrote:
> > As talked about in commit b792e64021ec ("drm: no need to check return
> > value of debugfs_create functions"), in many cases we can get away
> > with totally skipping checking the errors of debugfs functions. Let's
> > document that so people don't add new code that needlessly checks
> > these errors.
> > 
> > Probably this note could be added to a boatload of functions, but
> > that's a lot of duplication.  Let's just add it to the two most
> > frequent ones and hope people will get the idea.

There should not be many more debugfs functions that return a value,
right?  The number is getting smaller over time.

> Agreed. The first contact point for folks looking for the function's
> return values will probably be these two, I second that is enough.
> 
> > Suggested-by: Javier Martinez Canillas <javierm@...hat.com>
> > Signed-off-by: Douglas Anderson <dianders@...omium.org>
> > ---
> > 
> >  fs/debugfs/inode.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> > index 2f117c57160d..3dcf0b8b4e93 100644
> > --- a/fs/debugfs/inode.c
> > +++ b/fs/debugfs/inode.c
> > @@ -450,6 +450,11 @@ static struct dentry *__debugfs_create_file(const char *name, umode_t mode,
> >   *
> >   * If debugfs is not enabled in the kernel, the value -%ENODEV will be
> >   * returned.
> > + *
> > + * NOTE: it's expected that most callers should _ignore_ the errors returned
> > + * by this function. Other debugfs functions handle the fact that the "dentry"
> > + * passed to them could be an error and they don't crash in that case.
> > + * Drivers should generally work fine even if debugfs fails to init anyway.
> >   */
> 
> Thanks a lot for adding this. I was confused why the kernel doc didn't mention
> anything like that, yet most drivers didn't check and just ignored the errors.

I've been working on the kernel code first, to remove the checks, and
was going to revamp all of the documentation after this was all done.

thanks,

greg k-h