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

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

Message-ID: <CACT4Y+ZCvNu+-_FT=FMA6icB6x+2_E5-zo--PDnwR5X7tQ7O7w@mail.gmail.com>
Date: Wed, 17 Dec 2025 13:07:21 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Nathan Chancellor <nathan@...nel.org>
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, 17 Dec 2025 at 11:45, Nathan Chancellor <nathan@...nel.org> wrote:
>
> 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.

I am not typing commands in the console, I work on an automated system
that does not have a notion of "also do these custom changes to the
source tree at this particular point in the process".

> > 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),

The same stands for e.g. include/linux/sched.h.
kernel/sched/ext.c is just not a source file, it is a header file effectively.

> 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