linux-kernel - Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

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:	Thu, 28 Jul 2016 10:29:15 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	lkml <linux-kernel@...r.kernel.org>, Michael Matz <matz@...e.de>,
	linux-kbuild@...r.kernel.org, x86-ml <x86@...nel.org>
Subject: Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

* Borislav Petkov <bp@...en8.de> wrote:

> Hi Linus,
> 
> about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):
> 
> Good! Finally!
> 
> This thing was really getting on my nerves.

So I'm worried about this description in the changelog:

| Looking at the warnings produced, every single one I looked at was a false 
| positive, and the warnings are frequent enough (and big enough) that they can 
| easily hide real problems that you don't notice in the noise generated by 
| -Wmaybe-uninitialized.

BUT, isn't this the natural state of things, that the 'final' warnings that don't 
get fixed are the obnoxious, false positive ones - because anyone who looks at 
them will say "oh crap, idiotic compiler!"?

But over the last couple of years I think we probably had hundreds of bugs avoided 
due to the warning (both at the development and at the integration stage) - and 
now we are upset about a dozen residual warnings and declare it's all crap?

I am happy to bash GCC's cavalier attitude to warnings any day of the week, but 
this argumentation for this particular option looks fishy to me.

Why cannot we say something like:

 "a false_positive/false_negative ratio above 10% is considered obnoxious and
  won't be tolerated."

?

BTW., one related GCC property I'm pretty upset about: obvious false negatives for 
clear unused-variable bugs, which caused pain and hours of debugging. An example 
is this recent fix:

  commit e01d8718de4170373cd7fbf5cf6f9cb61cebb1e9
  Author: Peter Zijlstra <peterz@...radead.org>
  Date:   Wed Jan 27 23:24:29 2016 +0100

    perf/x86: Fix uninitialized value usage

  ...

  Only took 6 hours of painful debugging to find this. Neither GCC nor
  Smatch warnings flagged this bug.

... and my worry here is that we are now telling GCC: "don't you dare generate a 
false positive warning!" - at which point GCC folks will add even MORE heuristics 
to avoid false positives that generate even more false negatives which are hurting 
us asymmetrically more than the couple of low intensity minutes spent per false 
positive could ever hurt us ... ??

So what's the logic here? What am I missing?

Thanks,

	Ingo