linux-kernel - Re: [rfc] the kernel workflow & trivial "global -> static" patches

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]

Message-ID: <48203D3D.6000103@firstfloor.org>
Date:	Tue, 06 May 2008 13:13:01 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Alexander Viro <viro@....linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches

Adrian Bunk wrote:
> On Tue, May 06, 2008 at 02:21:31AM +0200, Andi Kleen wrote:
>> I don't think the code changes actually with current gcc for integer
>> code if you change something from global to static (unless it causes
>> gcc to inline the function, but then it might be well larger if you're
>> unlucky)
> 
> It's a common case that a function has only one caller. It should always 
> be an (at least tiny) space win to get them inlined.

At least for the scheduler patch that started this thread this was not
the case. One was a global variable and the other was a callback from
proc. Both cannot be inlined.

> There are many small aspects, e.g. both gcc with -Wmissing-prototypes 
> and sparse give warnings, and the problem might either be needlessly 
> global code or the fact that a function prototype is either not in a 
> header or the header not #include'd by the file. Although I've only
> 2 or 3 times catched such bugs in the kernel that is a nasty to debug 
> class of bugs and gcc can find such problems at compile time.

Yes it's good to catch those. However I suspect there are better tools
for that that do it less work intensive. Traditionally in the Unix
world "lint" has been used to track this kind of bugs (dating back from
before prototypes were added to C). Now running any lint over the kernel
source would result in a incredibly number of warnings I'm sure, but
perhaps one can be configured to only output warnings related to
inconsistent prototypes over files. There are a couple of free lints
like the one in NetBSD or splint.	

>> I could see some advantage from static in future compiler versions 
>> though from better optimization, but it's quite remote.
>> ...
> 
> The best case I've actually seen in practice was a variable I made 
> static, and with CONFIG_DEBUG_FOOBAR=n gcc was now able to prove that 
> the value never changed resulting in the variable plus quite a chunk
> of code no longer emitted.

Sounds like the variable should just have been removed then in the source?

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