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: <54c5930c-4006-4af9-8870-5d887bae7ac1@t-8ch.de>
Date: Tue, 22 Apr 2025 19:50:58 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Linus Torvalds <torvalds@...ux-foundation.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

On 2025-04-22 08:59:00-0700, Linus Torvalds wrote:
> On Tue, 22 Apr 2025 at 03:47, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > These builds were done with a gcc 11.1.0 cross compiler.
> 
> That sounds like there might be some issue with the cross-compiler
> logic somewhere, because the Makefile logic is using the standard
> 
>     KBUILD_CFLAGS += $(call cc-option, xyzzy)
> 
> pattern.  We literally have seven other occurrences of that same logic
> just in that same Makefile above it (and many more in other
> makefiles).

I think -Wno-foo is special here. By default GCC does not emit
a warning if it does not recognize a disabled warning.
This breaks the logic inside $(cc-option).
-Wfoo in contrast does emit a warning.

The original report said:
"cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics"

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

To disable warnings there is a dedicated macro.

$(call cc-disable-warning, unterminated-string-initialization)


Thomas

> IOW, it's *supposed* to only actually use the flag if the compiler
> supports it, so having the compiler then say "I don't recognize that
> option" is kind of odd. We've explicitly tested that the compiler
> supports it.
> 
> Does the warning happen for all files that get built, or just some
> specific ones? I wonder if we have some issue where we end up using
> two different compilers (I'd assume native and cross-built), and we
> use KBUILD_CFLAGS for the wrong compiler (or we use cc-option with the
> wrong compiler, but I'd expect that to affect *everything* - that
> 'cc-option' thing is not some kind of unusual pattern).
> 
> It may be that the other options we check for have been around for so
> long that they just don't show the issue (ie the 'cc-option' for the
> other cases may also be using the wrong compiler, but then it's hidden
> by the fact that both compiler versions just happen to support all the
> other options anyway).