Re: [PATCH] Revert "Enable '-Werror' by default for all kernel builds"

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]

On Tue, Sep 07, 2021 at 12:16:22PM -0700, Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 11:39 AM Nick Desaulniers
> <ndesaulniers@google.com> wrote:

> > The above commit seems as though it was merged in response to
> > https://lore.kernel.org/linux-hardening/CAHk-=wj4EG=kCOaqyPEq5VXa97kyUHsBpBn3DWwE91qcnDytOQ@mail.gmail.com/.

> No. It was merged in response of _years_ of pain, with the last one
> just being the final drop.

> I'm not going to revert that change. I probably will have to limit it
> (by making that WERROR option depend on certain expectations), but
> basically any maintainer who has code that causes warnings should
> expect that they will have to fix those warnings.

Echoing what others have said about runtime testing having -Werror on by
default for defconfigs is going to cause issues for bisection and just
generally noticing promptly when runtime issues are introduced - people
or systems bisecting boot or testsuite issues will encounter more blocks
of commits that they skip due to unrelated issues, and it's much more
likely that we'll just have gaps in coverage when for example the day's
-next has some random warning on some platforms.  In terms of
prioritisation it feels like the wrong call to have -Werror on
everywhere.

The bisection really is helpful, especially when the people looking at
the problem don't have direct access the systems to be able to run tests
themselves - it really increases the quality of reports when the
automation in CI services is able to identify the likely commit, and
makes it *much* more likely those reports be sent in the first place.

Of course this isn't insurmountable, the test systems can always add
config fragments to tweak the configurations they're testing (they
already need to do this to run lots of kselftest for example) but that's
something we've generally tried to minimise since everyone working with
custom configs has generally caused friction in the past.

> And it really shouldn't be "Linus cares about warnings, so
> configurations that Linus doesn't test can continue for years to have
> them".

> My "no warnings" policy isn't exactly new, and people shouldn't be
> shocked when I then say "time to clean up *YOUR* house too".

IME pushing on this stuff it's not that people don't care, it's that
they naturally have different test coverage due to their particular
interests and the resources available to them.  Even people who are very
dilligent in their own testing and paying a lot of attention to -next
and the automated test stuff that's out there are going to introduce
some breakage from time to time, and sometimes there's good reasons for
processes to get short circuited.

Some of this is also on the people doing the more niche stuff to keep on
top of reporting issues that come up as they do so, they should be able
to expect that people will pay attention when they do so but the more
niche you get the less surprising it is when nobody else notices issues.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]