linux-kernel - Re: [GIT PULL] Kbuild updates for v6.16-rc1

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: <20250612142938.10868H90-hca@linux.ibm.com>
Date: Thu, 12 Jun 2025 16:29:38 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: [GIT PULL] Kbuild updates for v6.16-rc1

On Thu, Jun 12, 2025 at 10:01:00AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> > On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@...db.de> wrote:
> >> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> >> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@...ux.ibm.com> wrote:
> >> I think this makes sense in general, but the output here is
> >> excessive if it leads to users no longer wanting to enable W=1.
> >>
> >> There are other warnings that I think should be enabled at the
> >> W=1 level (e.g. -Wformat-security) and eventually by default,
> >> but that are still too noisy at that level.
> >>
> >> My own cutoff would be at a few hundred warnings in allmodconfig
> >> builds if there is an effort to reduce it further, but it seems
> >> that this one is still at a few thousand, which does not seem ok.
> >
> > Then, what to do?  Downgrade to W=2?
> >
> > I think nobody cares about W=2 builds,
> 
> I think the first step would be mass-cleanup patches to get
> the initial numbers down. A lot of this can be scripted.

I'm not sure this should be separate patches which would then be sent for
review. This is way too much churn for something trivial like this. Only very
few patches have been posted yet, and discussions started:

https://lore.kernel.org/all/aEjwqtotEEH8QMHB@gondor.apana.org.au
https://lore.kernel.org/all/aEl9kO81-kp0hhw0@google.com
https://lore.kernel.org/all/CAHp75Vc7AO_sRgB1Nj6CevbseMFyv5ku8ZS3PwzAuAgysKVxNg@mail.gmail.com

This looks like the start of an immense waste of developer time.

Can't this be scripted and be addressed with a single commit shortly
after/before the next merge window closes?