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

Greg Kroah-Hartman gregkh at linuxfoundation.org
Thu Jun 13 17:42:15 UTC 2019


On Thu, Jun 13, 2019 at 05:27:55PM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 05:57:13PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jun 13, 2019 at 03:52:22PM +0100, Liviu Dudau wrote:
> > > On Thu, Jun 13, 2019 at 03:28:29PM +0200, 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.
> > > 
> > > I remember when writing this code and testing not fully complete code that left
> > > nodes around on removing the module that there were errors being returned by
> > > debugfs_create_file(). Has that changed since 2 years ago? :)
> > 
> > Errors can be returned if you do something foolish:
> > 	- pass an error as a parent pointer
> > 	- pass a name that is already present
> 
> That is what I was hitting previously. If we follow the new advice of not
> checking for errors does this mean I can now start to hide debugfs entries
> by touching some debugfs files before modules get loaded?

How can you "touch" a debugfs file today?

And even if there is a duplicate debugfs file, you shouldn't care as
your driver should keep going even if creation of it fails as no
functionality of the code should ever rely on debugfs.

thanks,

greg k-h


More information about the dri-devel mailing list