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]

Message-ID: <CA+55aFznBSQC+_KFq39eT2yTOd_cidqQ5viBLG6mshb_U_Y2EA@mail.gmail.com>
Date:	Thu, 28 Jul 2016 12:03:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Borislav Petkov <bp@...en8.de>, Sam Ravnborg <sam@...nborg.org>,
	lkml <linux-kernel@...r.kernel.org>, Michael Matz <matz@...e.de>,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	x86-ml <x86@...nel.org>
Subject: Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

On Thu, Jul 28, 2016 at 1:29 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> 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!"?

No. The *natural* state of things is very simple:

   Zero warnings.

End of story. No excuses.

We were there at 4.6 for me with an "allmodconfig" build.

In 4.7, we had over a hundred lines of warnings. That is SIMPLY UNACCEPTABLE.

And the new warnings were actually not so much due to new code in 4.7,
as the fact that in between I did a user-space upgrade, and gcc 6.1.1
has regressed to the point of the warnings being an unusable mess.

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

Nobody fixed the warnings, and looking at them, they were largely
unfixable without making the code worse.

Complain to the gcc people.

Remember: zero warnings.

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

It has nothing to do with "that particular option".  It has everything
to do with bad warnings in general.

Also, if you actually look at the patch, you'll see that that option
has already been disabled for a _lot_ of configurations because it was
already bad for most cases.

> Why cannot we say something like:
>
>  "a false_positive/false_negative ratio above 10% is considered obnoxious and
>   won't be tolerated."

Sure. I'm happy to do that.

What part of "100% of all the warnings were false positives, and won't
be tolerated" did you not get?

Once we get to the point that the warning is no longer useful, and is
more pain than gain, it gets disabled.

If you open a bugzilla and the gcc people actually react to it, we can
revisit it. But as it is, that warning had largely been disabled for
other configurations anyway, and I just made it go away entirely.

Because false positives that we can't fix without making the code
worse are not acceptable.

                 Linus