linux-kernel - Re: [PATCH 00/13] selftests: Fix problems seen when building with -Werror

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: <536d47f4-25b1-430a-820d-c22eb8a92c80@roeck-us.net>
Date: Thu, 4 Dec 2025 09:16:16 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Shuah Khan <shuah@...nel.org>, Christian Brauner <brauner@...nel.org>,
	Elizabeth Figura <zfigura@...eweavers.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Eric Dumazet <edumazet@...gle.com>, Kees Cook <kees@...nel.org>,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	wine-devel@...ehq.org, netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH 00/13] selftests: Fix problems seen when building with
 -Werror

On Thu, Dec 04, 2025 at 08:27:54AM -0800, Jakub Kicinski wrote:
> On Thu,  4 Dec 2025 08:17:14 -0800 Guenter Roeck wrote:
> > This series fixes build errors observed when trying to build selftests
> > with -Werror.
> 
> If your intention is to make -Werror the default please stop.
> Defaulting WERROR to enabled is one of the silliest things we have done
> in recent past.
> 

No, that is not the idea, and not the intention.

The Google infrastructure builds the kernel, including selftests, with
-Werror enabled. This triggers a number of build errors when trying to
build selftests with the 6.18 kernel. That means I have three options:
1) Disable -Werror in selftest builds and accept that some real problems
   will slip through. Not really a good option, and not acceptable.
2) Fix the problems in the upstream kernel and backport.
3) Fix the problems downstream only. Not really a good option but I guess
   we'll have to do it if this series (and/or follow-up patches needed to
   support glibc older than 2.36) is rejected.

We'll have to carry the patches downstream if 2) is rejected, but at
the very least I wanted to give it a try.

Guenter