linux-kernel - Re: [PATCH] get rid of some "may be used uninitialized" compiler warnings

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] [day] [month] [year] [list]

Message-ID: <20081129101346.GE26691@elte.hu>
Date:	Sat, 29 Nov 2008 11:13:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jirka Pirko <jirka@...ko.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] get rid of some "may be used uninitialized" compiler
	warnings

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Sat, 29 Nov 2008 10:26:01 +0100 Ingo Molnar <mingo@...e.hu> wrote:
> 
> >  196 files changed, 545 insertions(+), 436 deletions(-)
> 
> Is any of this going anywhere?

We are using it to allow -tip to build without a single warning in 
allyes/allno/allmod and randconfig kernels with -Werror, on 32-bit and 
64-bit x86. Hence we use it to filter out our own bogosities that come in 
via -tip maintained subsystems. (The fact that we need to look at _all_ 
warnings all across the kernel is a side effect.)

> There's a lot of resistance to fixing these things with 
> uninitialized_var() (usually bogus resistance, IMO, but one gets tired 
> of repeating oneself).

The networking tree picked up a whole bunch of them a few days ago. Most 
of the maintainers of actively maintained subsystems are reasonable about 
these things.

The only really contentious ones are the ones i kept separated out in 
tip/warnings/bug: they are the warnings that are triggered by 
!CONFIG_BUG.

> Many of these warnings can be fixed by restructuring the code, and 
> often the end result is better overall.

i can give you the identity of more than 1 million separate lines of code 
in the kernel where we have tool output that somehow tells us: "this code 
sucks and could be improved by restructuring it".

So the cleanup effect is there, but by far not as important as the other, 
reverse effect: a baseline of ~200 warnings obscures _nasty_ bugs that 
the compiler does point out. So we need to reach a zero baseline - and 
all the _new_ warnings tend to be very interesting.

We saw that in the x86 tree which reached a zero baseline -Werror a few 
months ago: out of 10 warnings fixed after we reached the baseline 9 were 
real fixes, only one is a GCC annotation.

I.e. we have amassed 100+ sites in the kernel that needs annotations - 
then we could move to the next phase and reliably enforce a -Werror build 
by subsystems who care about that. I know you care about it in -mm.

> But it's a lot more work.  It would be much more scalable to, umm, 
> motivate the various code-owners to fix their stuff independently.  I 
> don't know how, really - people just don't seem to appreciate how 
> irritating and damaging that great warning spew is.
> 
> Is there any prospect that some of these things will be fixed by newer 
> gcc versions?  If so, we could just ignore those warnings and 
> concentrate on the ones which newer gcc emits.

Some go away with new GCC versions - that is why i'm always testing with 
the very latest GCC version.

Would you be interested in picking up the ones in tip/warnings/complex 
and tip/warnings/simple [but not tip/warnings/bug] into -mm? You could 
pick up auto-warning-next tree into -mm straight away - it's well-tested 
on x86, it is -git based and kept uptodate. Then you could do 
!CONFIG_ALLOW_WARNINGS builds yourself.

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