[Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling

Das, Nirmoy Nirmoy.Das at amd.com
Fri Oct 8 12:08:50 UTC 2021


[AMD Official Use Only]

Thanks, Greg and Jani. So I have to do the exact opposite.

We do have some NULL dentry check in the drm code. I will remove those instead.

Regards,
Nirmoy
________________________________
From: Greg KH <gregkh at linuxfoundation.org>
Sent: Friday, October 8, 2021 1:07 PM
To: Jani Nikula <jani.nikula at linux.intel.com>
Cc: Das, Nirmoy <Nirmoy.Das at amd.com>; dri-devel at lists.freedesktop.org <dri-devel at lists.freedesktop.org>; intel-gfx at lists.freedesktop.org <intel-gfx at lists.freedesktop.org>; Maarten Lankhorst <maarten.lankhorst at linux.intel.com>; Maxime Ripard <mripard at kernel.org>; Thomas Zimmermann <tzimmermann at suse.de>; David Airlie <airlied at linux.ie>; Daniel Vetter <daniel at ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling

On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote:
> On Fri, 08 Oct 2021, Nirmoy Das <nirmoy.das at amd.com> wrote:
> > Debugfs API returns encoded error instead of NULL.
> > This patch cleanups drm debugfs error handling to
> > properly set dri and its minor's root dentry to NULL.
> >
> > Also do not error out if dri/minor debugfs directory
> > creation fails as a debugfs error is not a fatal error.
>
> Cc: Greg
>
> I thought this is the opposite of what Greg's been telling everyone to
> do with debugfs.

Yes, that is not good.

You should never care about the result of a debugfs_create* call.  Just
take the result, and if it is a directory, save it off to use it for
creating a file, no need to check anything.

And then throw it away, later, when you want to remove the directory,
look it up with a call to debugfs_lookup() and pass that to
debugfs_remove() (which does so recursively).

There should never be a need to save, or check, the result of any
debugfs call.  If so, odds are it is being used incorrectly.

thanks,

greg k-h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20211008/a6986e68/attachment-0001.htm>


More information about the Intel-gfx mailing list