linux-kernel - Re: [PATCH 3/8] platform: x86: dell-laptop: no need to check return value of debugfs

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Jun 2019 14:44:11 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     dvhart@...radead.org, andy@...radead.org,
        Matthew Garrett <mjg59@...f.ucam.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/8] platform: x86: dell-laptop: no need to check return
 value of debugfs_create functions

On Wednesday 12 June 2019 14:36:04 Greg Kroah-Hartman wrote:
> On Wed, Jun 12, 2019 at 02:21:05PM +0200, Pali Rohár wrote:
> > On Wednesday 12 June 2019 14:12:53 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: Matthew Garrett <mjg59@...f.ucam.org>
> > > Cc: "Pali Rohár" <pali.rohar@...il.com>
> > > Cc: Darren Hart <dvhart@...radead.org>
> > > Cc: Andy Shevchenko <andy@...radead.org>
> > > Cc: platform-driver-x86@...r.kernel.org
> > > Cc: linux-kernel@...r.kernel.org
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > ---
> > >  drivers/platform/x86/dell-laptop.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
> > > index a561f653cf13..94a2f259031c 100644
> > > --- a/drivers/platform/x86/dell-laptop.c
> > > +++ b/drivers/platform/x86/dell-laptop.c
> > > @@ -2176,9 +2176,8 @@ static int __init dell_init(void)
> > >  	kbd_led_init(&platform_device->dev);
> > >  
> > >  	dell_laptop_dir = debugfs_create_dir("dell_laptop", NULL);
> > > -	if (dell_laptop_dir != NULL)
> > > -		debugfs_create_file("rfkill", 0444, dell_laptop_dir, NULL,
> > > -				    &dell_debugfs_fops);
> > > +	debugfs_create_file("rfkill", 0444, dell_laptop_dir, NULL,
> > > +			    &dell_debugfs_fops);
> > 
> > Hi!
> > 
> > So... debugfs_create_dir() can return NULL, right?
> 
> Nope.

Yea, now I see implementation. It does not return NULL on error, but
rather ERR_PTR.

So dell_laptop_dir is always not-NULL. And that check was wrong.

You can add my
Reviewed-by: Pali Rohár <pali.rohar@...il.com>

> > And it is then OK to call
> > debugfs_create_file("rfkill", 0444, dell_laptop_dir, ...) with
> > dell_laptop_dir = NULL?
> 
> Yes.
> 
> > Where would be that "rfkill" file created?
> 
> The root of debugfs.
> 
> But, if debugfs_create_dir() return an error, and you pass that value
> into debugfs_create_file() it will happily just return an error back
> again, and move on.
> 
> So it is always safe to pass the return value of one debugfs call into
> another, no need to check anything.  If the system is so messed up that
> debugfs_create_dir() fails (i.e. you are out of memory), failing to
> create a debugfs file is the least of your worries :)
> 
> And even then, no need to change your code logic, the functionality of
> your code should never depend on if debugfs is working properly at the
> moment or not.
> 
> thanks,
> 
> greg k-h

-- 
Pali Rohár
pali.rohar@...il.com