[PATCH] debugfs: Document that debugfs_create functions need not be error checked

[PATCH] debugfs: Document that debugfs_create functions need not be error checked

[Douglas Anderson]

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.

Suggested-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Douglas Anderson <dianders@chromium.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.
  */
 struct dentry *debugfs_create_file(const char *name, umode_t mode,
 				   struct dentry *parent, void *data,
@@ -551,6 +556,11 @@ EXPORT_SYMBOL_GPL(debugfs_create_file_size);
  *
  * 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.
  */
 struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
 {
-- 
2.35.1.473.g83b2b277ed-goog

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

[Javier Martinez Canillas]

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.
> 

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@redhat.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.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.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

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

[Greg Kroah-Hartman]

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@redhat.com>
> > Signed-off-by: Douglas Anderson <dianders@chromium.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