netdev - Re: [PATCH] proc: proc_create() should return true if CONFIG_PROC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Feb 2015 16:22:37 -0500
From:	Jonathon Reinhart <jonathon.reinhart@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Zhang Zhaolong <zhangzl2013@....com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH] proc: proc_create() should return true if CONFIG_PROC_FS
 is not configured

On Wed, Feb 25, 2015 at 6:19 AM, David Howells <dhowells@...hat.com> wrote:
>> Does that even compile? proc_create() and proc_create_data() both return
>> "struct proc_dir_entry *". It doesn't make sense for those macros to "return"
>> anything but NULL - certainly not 1.
>>
>> Besides, why shouldn't "if (!proc_create())" behave like proc_create()
>> failed when
>> CONFIG_PROC_FS is not enabled?  You wouldn't want the caller to start trying
>> to use that ((struct proc_dir_entry *)1) would you?
>
> It's sort of arguable.  If the proc interface is merely informational and
> doesn't impact the function of a module to not be present, then, yes, having
> proc_create() return some "true" value might make sense.  It's possible to
> arrange things so that all the proc-related functions and data get compiled
> out in such a situation by not being referenced by anything.
>
> However, if the proc interface isn't merely functional, then the proc_create()
> failure *is* cause for module loading failure.  But in that case, there should
> be a Kconfig dependency on procfs and you should never use the dummy
> functions.

Of the 528 calls to proc_create(_data), only 70 are in an "if (!proc_create())"
style conditional. Another 188 assign the result to something, presumably a
"struct proc_dir_entry *, which are going to fail compilation with this patch.

Is breaking the build when the result of these dummy functions are assigned
to something what you're after? If that's the case, then why not remove them
altogether?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html