linux-kernel - Re: [PATCH 6/7] crypto: ccp: 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, 23 Jan 2019 07:55:56 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Gary R Hook <ghook@....com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "Hook, Gary" <Gary.Hook@....com>
Subject: Re: [PATCH 6/7] crypto: ccp: no need to check return value of
 debugfs_create functions

On Tue, Jan 22, 2019 at 10:06:54PM +0000, Gary R Hook wrote:
> On 1/22/19 9:14 AM, 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.
> 
> Stupid question(s) time.
> 
> If we don't care about failures (because the subsystem handles them 
> without our involvement) why do these functions even have return values? 
> Why haven't they been changed to void so that they reflect the current 
> style of intended use?

Because on "normal" operations, you use the return value for something
(i.e. a parent directory to pass to other functions, or a value so you
can remove the file later).

> I realize I'm old fashioned, but if a failure occurs, I've always been 
> of a mind to kick out and not try to do any further work. But debugfs is 
> to be treated as an exception to that paradigm? Carry on, ignore errors, 
> don't worry about it?

Yes, that is the case here, it goes against what everyone normally
thinks about kernel development :)

thanks,

greg k-h