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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250401191455.GC325917@nvidia.com>
Date: Tue, 1 Apr 2025 16:14:55 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	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:46:34AM +0900, Masahiro Yamada wrote:
> However, it is annoying to make every header self-contained
> "just because we are checking this".

>From my POV itis not "just because we are checking this", I have a
very deliberate reason for wanting headers to be self contained:

I want the clangd code indexer and editor integration to work fully.

When clangd is asked by the editor for a report on a header file it
cannot know the missing implicit includes and it's functionality is
degraded. It reports fake compilation errors, can't do all the
indexing functions, and is generally a bad experience. To be clear the
header is parsed and loaded into the database when some C file
included it, just the actual editing of the header doesn't work well.

This is a very big day-to-day negative for working on the code. I'm
frequently annoyed by headers that are pointlessly not self
contained. I'd really welcome someone doing a cleanup here.

I agree it should not be a hard rule. I was reading the thread you
linked to and I'm thinking the approach is not optimal.

The only header files that should be checked are ones that are
actually used as part of the build with the current kconfig. Christoph
is right that there are endless cases where headers should never be
parsed outside of specific kconfig settings.

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.

Jason