linux-kernel - Re: Build failure: -Wno-unused-const-variable DNE on old GCC

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, 7 Jan 2016 15:02:25 -0800
From:	Brian Norris <computersforpeace@...il.com>
To:	Daniel Axtens <dja@...ens.net>
Cc:	Arnd Bergmann <arnd@...db.de>, linuxppc-dev@...ts.ozlabs.org,
	Michael Ellerman <mpe@...erman.id.au>,
	Michael Neuling <mikey@...ling.org>,
	Anton Blanchard <anton@....ibm.com>,
	linux-kernel@...r.kernel.org, Michal Marek <mmarek@...e.com>,
	Ian Munsie <imunsie@....ibm.com>
Subject: Re: Build failure: -Wno-unused-const-variable DNE on old GCC

On Fri, Jan 08, 2016 at 09:51:35AM +1100, Daniel Axtens wrote:
> 
> > Alternatively, remove the -Werror. We occasionally get people that add this
> > flag to a Makefile, but it tends to cause more trouble whenever a new
> > gcc version arrives.

^^ Your reasons below don't really address this point. No matter how
well you patch a later kernel release, you can't fix a problem in an
existing kernel release that is triggered by a new warning in a new
compiler. This shouldn't cause a build failure.

> Speaking up as the person who added -Werror to cxl, I'd really rather
> it stayed. There are a number of reasons I think this. Here's the first
> three that came to mind.
> 
>  - cxl is powerpc specific (and always will be for deep seated hardware
>    reasons), and is handled through the powerpc tree. arch/powerpc
>    compiles with -Werror, and as part of the powerpc ecosystem, cxl
>    should too.
> 
>  - It forces cxl developers to a higher standard. cxl has already had
>    more than it's fair share of incredibly difficult to debug issues,
>    so any way we can reduce the risk of errors going in makes our lives
>    (and our end-users lives) better.

One problem with this point: not all warnings are under the purview of
cxl developers. For instance, if I turn up warning verbosity (W=1), then
the *header* files start producing plenty of warnings. Should this break
the build? Your code didn't change, and you can't fix those errors.

That is a real use case for me daily: I turn the warning verbosity up on
my compile tests, then (smart)diff the build logs before and after
new patches. That way, I can see what new warnings (even potentially
false positive ones) are introduced. I can't do that if every random
developer wants to stick -Werror in their Makefile.

>  - I am (and I'm quite confident the other cxl people are) quite happy to
>    send patches to fix build-breaking issues such as this. Indeed, I
>    would have, except you sent it during the Australian night :)
> 
> If it's really super-duper important we can consider putting it behind a
> config guard, but I'd really rather not.

I think there are plenty of reasons to either remove -Werror, or make it
configurable. Some of them are detailed above.

Maybe you can gate the -Werror on CONFIG_PPC_WERROR, just like the rest
of PowerPC?

Brian