Re: securityfs_create_dir strange comment

[Jan Engelhardt <jengelh@linux01.gwdg.de>]

Hi Greg,

>> >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 we're back to the confusing comment ;-)

>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...

I have actually had a look into the tree who even uses securityfs.
The most prominent case are LSMs. They need CONFIG_SECURITY=y anyway,
so securityfs is always enabled for those. What remains seems to be
tpm_bios.c.


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