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: <38a08452-4db2-43e0-afdc-b7d696da5454@app.fastmail.com>
Date: Thu, 12 Jun 2025 10:01:00 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Masahiro Yamada" <masahiroy@...nel.org>
Cc: "Heiko Carstens" <hca@...ux.ibm.com>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 "Linux Kbuild mailing list" <linux-kbuild@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v6.16-rc1

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.

> and the problem of all C files including <linux/export.h>
> would remain forever.

I'm missing a bit of background here, and I don't see this
explained in the 5b20755b7780 ("init: move THIS_MODULE
from <linux/export.h> to <linux/init.h>") changelog text
either

What is the purpose of cleaning the linux/export.h inclusions,
and what makes this one more important than others?
I obviously understand that indirect header inclusions are
a giant mess and that any such cleanup helps, but linux/export.h
seems particularly small compared to many others. It was
originally introduced so a lot of files would no longer have
to pull in linux/module.h if they only care about using
EXPORT_SYMBOL() and THIS_MODULE, so linux/module.h could
eventually become private to kernel/module/*.c.

Is this something you are trying to continue, or are you
doing something else here?

FWIW, I compared the preprocessed sizes of linux/export.h
(~2000) and linux/module.h (~120,000), and it seems that almost
none of those are needed by most of the files including
linux/module.h. The one part that is commonly required is
MODULE_{INFO,AUTHOR,LICENSE,DESCRIPTION}, so maybe there would
be a chance to clean this up at the same time if you are
planning some large-scale reshuffling of #include statements
around export.h.

     Arnd