linux-kernel - Re: [PATCH v2 0/4] kbuild: resurrect generic header check facility

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] [day] [month] [year] [list]

Message-ID: <20250407171209.GJ1557073@nvidia.com>
Date: Mon, 7 Apr 2025 14:12:09 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Jani Nikula <jani.nikula@...el.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, David Airlie <airlied@...il.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	linux-kbuild@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	intel-xe@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org
Subject: Re: [PATCH v2 0/4] kbuild: resurrect generic header check facility

On Mon, Apr 07, 2025 at 10:17:40AM +0300, Jani Nikula wrote:

> Even with Jason's idea [1], you *still* have to start small and opt-in
> (i.e. the patch series at hand). You can't just start off by testing
> every header in one go, because it's a flag day switch. 

You'd add something like 'make header_check' that does not run
automatically. Making it run automatically after everything is fixed
to keep it fixed would be the flag day change. It is how we have
managed to introduce other warning levels in the past.

If you added the infrastructure there is a whole list of people on
kernel-janitors that would probably help with the trivial cleanups to
make it run clean.

> With this type of antagonistic rather than encouraging attitude towards
> contributions, there's just no way I can justify to myself (or my
> employer) spending more time on what looks like a wild goose chase. I
> have zero confidence that no matter what I do I'd get approval from you.

I think you've been given a clear direction on what would be accepted
and have the option to persue it. Claiming that is "antagonistic"
seems unnecessary.

> And this is the primary reason subsystems and drivers hack up stuff in
> their little corners of the kernel instead of sticking their necks out
> and trying to generalize anything.

Seems to me like this is the usual case of generalizing being actually
hard, you almost always have to actually do more work to succeed.

Jason