linux-kernel - Re: [git pull] drm for 6.15-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: <20250402130347.GB342109@nvidia.com>
Date: Wed, 2 Apr 2025 10:03:47 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...il.com>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.15-rc1

On Wed, Apr 02, 2025 at 03:56:37PM +0300, Jani Nikula wrote:
> On Tue, 01 Apr 2025, Jason Gunthorpe <jgg@...dia.com> wrote:
> > On Tue, Apr 01, 2025 at 10:42:35PM +0300, Jani Nikula wrote:
> >> On Tue, 01 Apr 2025, Jason Gunthorpe <jgg@...dia.com> wrote:
> >> > So, I'd suggest a better way to run this is first build the kernel,
> >> > then mine the gcc -MD output (ie stored in the .XX.cmd files) to
> >> > generate a list of headers that are actually part of the build, then
> >> > only test those. That eliminates all the kconfig problems. Opt out any
> >> > special headers that really have a good reason not to be stand alone.
> >> 
> >> I think we'd want the drm headers pass the checks independent of configs
> >> (apart from CONFIG_DRM). One size doesn't fit all.
> >
> > Why? That demand is just making it impossible to make shared
> > infrastructure, and I don't think DRM should go off and build its own
> > stuff just for DRM in a way that nobody else can use it.
> >
> > If you really, really, care then you can have your makefile codegen an
> > "allheaders.c" that #includes drm/*.h and compile that.
> 
> The v2 series [1] generalizes the header checks and it's no longer in
> any way dependent on DRM. For starters, each subsystem/driver needs to
> decide for themselves which headers are to be checked.

Yuk. The idea at the top of this email is alot better. Why don't you
implement it?

> This can be expanded with more clever ways to choose the headers to
> check. But we have to start *somewhere*.

Bah, that argument only works if nobody has better ideas. There are
meaningful technical problems with your approach, and proposed
solutions here.

Jason