linux-kernel - Re: securityfs_create

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]

Message-ID: <20070221172949.GA16029@kroah.com>
Date:	Wed, 21 Feb 2007 09:29:49 -0800
From:	Greg KH <greg@...ah.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: securityfs_create_dir strange comment

On Wed, Feb 21, 2007 at 06:07:56PM +0100, Jan Engelhardt wrote:
> Hello Greg,
> 
> 
> On Feb 20 2007 20:05, Greg KH wrote:
> >
> >Try this instead:
> >	if (!de)
> >		return -ENOMEM;
> >	if ((IS_ERR(de)) && (PTR_ERR(de) != -ENODEV))
> >		return PTR_ERR(de);
> >	return 0;
> >
> >That should cover everything properly, right?
> 
> In case memory could not be allocated, why does not securityfs_*() return
> ERR_PTR(-ENOMEM) then? (I think, that's the quintessential question after
> all. And thanks for giving an example what to do in the ENODEV case.)

Actually, in reading the code (which might have helped in the first
place), we can never return NULL if securityfs is enabled.  So you can
just drop that first check entirely.

Which makes me wonder, it might be easier to just return NULL if
securityfs is not enabled in the kernel, as long as no one checks that
improperly...

Hope this helps,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/