linux-kernel - Re: [GIT PULL] kbuild changes for v6.19

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: <20251217104517.GA3546346@ax162>
Date: Wed, 17 Dec 2025 19:45:17 +0900
From: Nathan Chancellor <nathan@...nel.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Nicolas Schier <nsc@...nel.org>, patso@...ewhatevs.io,
	Justin Stitt <justinstitt@...gle.com>, eddyz87@...il.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	regressions@...ts.linux.dev
Subject: Re: [GIT PULL] kbuild changes for v6.19

On Wed, Dec 17, 2025 at 11:16:37AM +0100, Dmitry Vyukov wrote:
> Yikes! I am trying to workaround this, but this is PITA.
> Entries are not in order, + there are now multiple entries for the
> same source file (yes, files include themselves). This is plain
> broken, and hard to workaround. Even if I find the entry that is
> correct, I can't really tell about it to a clang tool since it accepts
> just the source file name, and there are multiple entries for the same
> file name.
> 
> Does anybody see a reasonable way to undo what this commit is doing?

Does

  $ git revert 9362d34acf91a706c543d919ade3e651b9bd2d6f

not work for you? It is a clean revert for me.

> Thinking about this: I think included source files should be treated
> as include files by anything, rather than added to the database. They
> _are_ include files, and systems should handle include files already.

The commit message of 9362d34acf91 mentions that clangd does not work
properly with the files that are included in kernel/sched/build_policy.c
(such as kernel/sched/ext.c) because there are no entries for them in
compile_commmands.json (so it does not know how to build them), which is
what 9362d34acf91 was trying to fix. I don't use clangd or
compile_commands.json, so I can't say if there is a way for the tool
itself to fix this. Again, unless Pat can come up with some way to work
around this (which I do not personally see at this point), I think we
would be better off just reverting 9362d34acf91 outright and calling the
situation of including .c files within other .c files broken for
compile_commands.json and returning to the status quo from 6.18 and
earlier.

Cheers,
Nathan