linux-kernel - Re: linux-next: build warning after merge of Linus' tree

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: <CAHk-=whv79F+zTKPa3yygTWnC+z9gRtPOdj_aBegWXtWB3D9=A@mail.gmail.com>
Date: Tue, 22 Apr 2025 11:20:21 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Weißschuh <linux@...ssschuh.net>, 
	Masahiro Yamada <masahiroy@...nel.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build warning after merge of Linus' tree

[ Adding Masahiro explicitly in case we can just fix cc-option. See below. ]

On Tue, 22 Apr 2025 at 10:51, Thomas Weißschuh <linux@...ssschuh.net> wrote:
>
> To disable warnings there is a dedicated macro.
>
> $(call cc-disable-warning, unterminated-string-initialization)

Heh. We have several other cases of that "disable warning" pattern
that does *not* use that cc-disable-warning thing.

In fact, right next to the new unterminated-string-initialization case
(just a couple of lines above it), we have a

   $(call cc-option, -Wno-stringop-overflow)

thing, along with several cases in loongarch and riscv.

So they are presumably _also_ broken, but perhaps just happened to
silently work due to compiler versions (and that stringop-overflow
case is gated by a config option that might also have hidden it from
people).

And as you say:

> Note the "earlier diagnostics" wording. And indeed the real reported
> issue is "warning: #warning syscall clone3 not implemented [-Wcpp]"

so apparently it *also* requires other warnings to actually trigger
problems, which is presumably why Stephen only sees this issue on
sparc* targets.

And which is probably the main reason why the problems with other
cases of this same issue haven't been noted.

Now, the obvious fix is to just convert all these cases to
'cc-disable-warning', and I'll do that.

But exactly because we have at least nine cases of this, maybe we
could make cc-option actually work for this by forcing that "earlier
diagnostics" case in the cc-option test?

Right now cc-option uses -Werror to turn all the warnings into errors,
and thus causes a "unrecognized compiler option" warning to be fatal.

But what if we were to add an intentional warning to the cc-options
test-case, and use -Wno-error-XYZ to make just *that* warning be
harmless, and then 'cc-option' would work for the unrecognized
command-line options for the -Wno-xyz case too?

Because even after I fix all the nine cases we've now accumulated, I
bet we'll have more in the future - just because 'cc-option' is so
much more common (a quick grep shows 429 vs 40 occurrences).

               Linus