linux-kernel - Re: [PATCH 1/7][QUOTA] Move sysctl management code under ifdef CONFIG

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:	Tue, 04 Dec 2007 12:31:37 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	ebiederm@...ssion.com, linux-kernel@...r.kernel.org,
	devel@...nvz.org
Subject: Re: [PATCH 1/7][QUOTA] Move sysctl management code under ifdef CONFIG_SYSCTL

Andrew Morton wrote:
> On Tue, 04 Dec 2007 11:58:30 +0300 Pavel Emelyanov <xemul@...nvz.org> wrote:
> 
>>>> +#ifdef CONFIG_SYSCTL
>>>>  	register_sysctl_table(sys_table);
>>>> +#endif
>>>>  
>>>>  	dquot_cachep = kmem_cache_create("dquot",
>>>>  			sizeof(struct dquot), sizeof(unsigned long) * 4,
>>> We should avoid the ifdefs around the register_sysctl_table() call.
>>>
>>> At present the !CONFIG_SYSCTL implementation of register_sysctl_table() is
>>> a non-inlined NULL-returning stub.  All we have to do is to inline that stub
>>> then these ifdefs can go away.
>> What if some code checks for the return value to be not-NULL? In case
>> CONFIG_SYSCTL=n this code will always think, that the registration failed.
> 
> The stub function should return success?

Well, I think yes. If some functionality is turned off, then the 
caller should think that everything is going fine (or he should
explicitly removes the call to it with some other ifdef). 

At least this is true for stubs that return the error code, not 
the pointer. E.g. copy_semundo() always returns success if SYSVIPC 
is off, or namespaces cloning routines act in a similar way.

Thus I though, that routines, that return pointers should better
report that everything is OK (somehow) to reduce the number of 
"helpers" in the outer code. No?

Thanks,
Pavel

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