kbuild changes for v6.19

Hi Linus,

please pull these update to Kbuild for v6.19. This is my first pull request, so please let me know if anything is incorrect and not matching your standards.

All changes have been in -next, most for several cycles without reported problems.

Non-native kbuild changes are related to addition of -fms-extensions and a conversion example; as well as for the userspace CC_CAN_LINK addition.

Thanks and kind regards,
Nicolas

----------------------------------------------------------------

The following changes since commit 211ddde0823f1442e4ad052a2f30f050145ccada:

Linux 6.18-rc2 (2025-10-19 15:19:16 -1000)

are available in the Git repository at:

ssh://[email protected]/pub/scm/linux/kernel/git/kbuild/linux.git tags/kbuild-6.19-1

for you to fetch changes up to 2a9c8c0b59d366acabb8f891e84569376f3e2709:

kbuild: add target to build a cpio containing modules (2025-11-26 21:56:14 +0100)

----------------------------------------------------------------
Kbuild updates for v6.19

- Enable -fms-extensions, allowing anonymous use of tagged struct or union in struct/union (tag kbuild-ms-extensions-6.19). An exemplary conversion patch is added here, too (btrfs).

- Introduce architecture-specific CC_CAN_LINK and flags for userprogs

- Add new packaging target 'modules-cpio-pkg' for building a initramfs cpio w/ kmods

- Handle included .c files in gen_compile_commands

- Minor kbuild changes:
- Use objtree for module signing key path, fixing oot kmod signing
- Improve documentation of KBUILD_BUILD_TIMESTAMP
- Reuse KBUILD_USERCFLAGS for UAPI, instead of defining twice
- Rename scripts/Makefile.extrawarn to Makefile.warn
- Drop obsolete types.h check from headers_check.pl
- Remove outdated config leak ignore entries

Signed-off-by Nicolas Schier <[email protected]>

----------------------------------------------------------------
Ahmad Fatoum (1):
initramfs: add gen_init_cpio to hostprogs unconditionally

Gang Yan (1):
kbuild: doc: improve KBUILD_BUILD_TIMESTAMP documentation

Mikhail Malyshev (1):
kbuild: Use objtree for module signing key path

Nathan Chancellor (4):
jfs: Rename _inline to avoid conflict with clang's '-fms-extensions'
kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS
kbuild: Rename Makefile.extrawarn to Makefile.warn
kbuild: uapi: Drop types.h check from headers_check.pl

Nicolas Schier (3):
Merge tag 'kbuild-ms-extensions-6.19' into kbuild-next MAINTAINERS, .mailmap: Update mail address for Nicolas Schier
scripts: headers_install.sh: Remove two outdated config leak ignore entries

Pat Somaru (1):
scripts/clang-tools: Handle included .c files in gen_compile_commands

Quoted 2 lines · Nicolas Schier

Pat Somaru (1):
scripts/clang-tools: Handle included .c files in gen_compile_commands

/\/\/\/\/\/\/\

This commit breaks invocation of clang tools for me.

For example I now have this fake entry for mock_uncore.c which pretends to produce intel_uncore.o (along with 2 other commands which produce the same object file):

An attempt to invoke a clang tool using this database legitimately fails with the following errors (the file is not supposed and can't compile on its own):

clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1 drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |                                              ^~~
      |                                              nopv

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |                                             ^~~
      |                                             nopv

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
4 errors generated.
Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.

What am I doing wrong?

Quoted 11 lines · Dmitry Vyukov

Quoted 2 lines · Nicolas Schier

Pat Somaru (1):
scripts/clang-tools: Handle included .c files in gen_compile_commands

/\/\/\/\/\/\/\

This commit breaks invocation of clang tools for me.

For example I now have this fake entry for mock_uncore.c which pretends to produce intel_uncore.o (along with 2 other commands which produce the same object file):

...

Quoted 30 lines

An attempt to invoke a clang tool using this database legitimately fails with the following errors (the file is not supposed and can't compile on its own):

clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1 drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |                                              ^~~
      |                                              nopv

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |                                             ^~~
      |                                             nopv

Quoted 8 lines

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
4 errors generated.
Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.

What am I doing wrong?

Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in drivers/gpu/drm/i915/intel_uncore.c but it is used in drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to be built standalone. We could potentially move ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I think I would rather just revert 9362d34acf91, as I already figured that this was going to be fragile:

https://lore.kernel.org/20251007163338.GA547361@ax162/

I would rather discourage including .c files if folks want clangd to work properly since this seems fundamentally unsolvable if developers have written .c files in this manner. I am open to other thoughts though.

Quoted 58 lines

Quoted 10 lines

Quoted 2 lines

Pat Somaru (1):
scripts/clang-tools: Handle included .c files in gen_compile_commands

/\/\/\/\/\/\/\

This commit breaks invocation of clang tools for me.

For example I now have this fake entry for mock_uncore.c which pretends to produce intel_uncore.o (along with 2 other commands which produce the same object file):

...

Quoted 30 lines

An attempt to invoke a clang tool using this database legitimately fails with the following errors (the file is not supposed and can't compile on its own):

clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1 drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
      |                                              ^~~
      |                                              nopv

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |         ^
drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
undeclared identifier 'nop'; did you mean 'nopv'?
   48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
      |                                             ^~~
      |                                             nopv

Quoted 8 lines

/arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
71 | extern bool nopv;
| ^
4 errors generated.
Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.

What am I doing wrong?

Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in drivers/gpu/drm/i915/intel_uncore.c but it is used in drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to be built standalone. We could potentially move ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I think I would rather just revert 9362d34acf91, as I already figured that this was going to be fragile:

Quoted 6 lines

https://lore.kernel.org/20251007163338.GA547361@ax162/

I would rather discourage including .c files if folks want clangd to work properly since this seems fundamentally unsolvable if developers have written .c files in this manner. I am open to other thoughts though.

I am not sure what other clang tools are doing, and why they need this. But FWIW my clang tools don't need it at all. They would index all files, get source files from AST (which would include included .c files as well), and work with that index. So they natively "see" and understand all included .c files.

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?

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.

Quoted 8 lines · Dmitry Vyukov

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.

Quoted 1 line

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.

Quoted 3 lines

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

Quoted 6 lines

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.

Quoted 10 lines · Nathan Chancellor

Quoted 8 lines · Dmitry Vyukov

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.

Quoted 7 lines

Quoted 1 line

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".

Quoted 8 lines

Quoted 3 lines

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.

Quoted 12 lines

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