The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
get information about builtin modules. Among other information about the module,
information about module aliases is stored. This is very important to determine
that a particular modalias will be handled by a module that is inside the
kernel.

There are several mechanisms for creating modalias for modules:

The first is to explicitly specify the MODULE_ALIAS of the macro. In this case,
the aliases go into the '.modinfo' section of the module if it is compiled
separately or into vmlinux.o if it is builtin into the kernel.

The second is the use of MODULE_DEVICE_TABLE followed by the use of the
modpost utility. In this case, vmlinux.o no longer has this information and
does not get it into modules.builtin.modinfo.

For example:

$ modinfo pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30
modinfo: ERROR: Module pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 not found.

$ modinfo xhci_pci
name:           xhci_pci
filename:       (builtin)
license:        GPL
file:           drivers/usb/host/xhci-pci
description:    xHCI PCI Host Controller Driver

The builtin module is missing alias "pci:v*d*sv*sd*bc0Csc03i30*" which will be
generated by modpost if the module is built separately.

To fix this it is necessary to add the generated by modpost modalias to
modules.builtin.modinfo. Fortunately modpost already generates .vmlinux.export.c
for exported symbols. It is possible to add `.modinfo` for builtin modules and
modify the build system so that `.modinfo` section is extracted from the
intermediate vmlinux after modpost is executed.

---
Notes:
- v8:
  * Fix build warnings about unused variable.
  * Fix objcopy "warning: empty loadable segment detected ...".
  * v7: https://lore.kernel.org/all/cover.1755535876.git.legion@kernel.org/

- v7:
  * Reorder patches to avoid unnecessary linker warnings on s390.
  * Drop the patch for pinctrl since it's already been applied.
  * v6: https://lore.kernel.org/all/cover.1755170493.git.legion@kernel.org/

- v6:
  * Rebase to v6.17-rc1-16-g8742b2d8935f to pick up the fixes made by Masahiro Yamada.
  * Fix an issue on i386 configs caused by the use of string_32.h.
  * v5: https://lore.kernel.org/all/cover.1753354215.git.legion@kernel.org/

- v5:
  * Rebase to v6.16-rc6-281-gf4a40a4282f4 to pick up the fixes made by Masahiro Yamada.
  * Attempt to fix linker warning on s390.
  * Fix typo in pinctrl/meson found by the kernel test robot.
  * v4: https://lore.kernel.org/all/cover.1750511018.git.legion@kernel.org/

- v4:
  * Rework the patchset based on top of Masahiro Yamada's patches.
  * Add removal of unnecessary __mod_device_table__* symbols to avoid symbol
    table growth in vmlinux.
  * rust code takes into account changes in __mod_device_table__*.
  * v3: https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/

- v3:
  * Add `Reviewed-by` tag to patches from Petr Pavlu.
  * Rebase to v6.15.
  * v2: https://lore.kernel.org/all/20250509164237.2886508-1-legion@kernel.org/

- v2:
  * Drop patch for mfd because it was already applied and is in linux-next.
  * The generation of aliases for builtin modules has been redone as
    suggested by Masahiro Yamada.
  * Rebase to v6.15-rc5-136-g9c69f8884904
  * v1: https://lore.kernel.org/all/cover.1745591072.git.legion@kernel.org/


Alexey Gladkov (5):
  s390: vmlinux.lds.S: Reorder sections
  scsi: Always define blogic_pci_tbl structure
  modpost: Add modname to mod_device_table alias
  modpost: Create modalias for builtin modules
  kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o

Masahiro Yamada (3):
  kbuild: always create intermediate vmlinux.unstripped
  kbuild: keep .modinfo section in vmlinux.unstripped
  kbuild: extract modules.builtin.modinfo from vmlinux.unstripped

 arch/s390/kernel/vmlinux.lds.S    | 10 ++--
 drivers/scsi/BusLogic.c           |  4 +-
 include/asm-generic/vmlinux.lds.h |  2 +-
 include/linux/module.h            | 18 +++++--
 rust/kernel/device_id.rs          |  8 ++--
 scripts/Makefile.vmlinux          | 79 ++++++++++++++++++++-----------
 scripts/Makefile.vmlinux_o        | 26 +---------
 scripts/link-vmlinux.sh           |  5 +-
 scripts/mksysmap                  |  6 +++
 scripts/mod/file2alias.c          | 34 +++++++++++--
 scripts/mod/modpost.c             | 15 ++++++
 scripts/mod/modpost.h             |  2 +
 12 files changed, 131 insertions(+), 78 deletions(-)


base-commit: aa943a280e88e3585ed5a06d55e78c4123fcead3
-- 
2.51.0

On Thu, 18 Sep 2025 10:05:44 +0200, Alexey Gladkov wrote:
> The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
> get information about builtin modules. Among other information about the module,
> information about module aliases is stored. This is very important to determine
> that a particular modalias will be handled by a module that is inside the
> kernel.
> 
> There are several mechanisms for creating modalias for modules:
> 
> [...]

Applied, thanks!

[1/8] s390: vmlinux.lds.S: Reorder sections
      https://git.kernel.org/kbuild/c/8d18ef04f940a
[2/8] kbuild: always create intermediate vmlinux.unstripped
      https://git.kernel.org/kbuild/c/0ce5139fd96e9
[3/8] kbuild: keep .modinfo section in vmlinux.unstripped
      https://git.kernel.org/kbuild/c/3e86e4d74c049
[4/8] kbuild: extract modules.builtin.modinfo from vmlinux.unstripped
      https://git.kernel.org/kbuild/c/39cfd5b12160b
[5/8] scsi: Always define blogic_pci_tbl structure
      https://git.kernel.org/kbuild/c/b88f88c26705a
[6/8] modpost: Add modname to mod_device_table alias
      https://git.kernel.org/kbuild/c/83fb49389bbe0
[7/8] modpost: Create modalias for builtin modules
      https://git.kernel.org/kbuild/c/5ab23c7923a1d
[8/8] kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o
      https://git.kernel.org/kbuild/c/3328d39a8dca2

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>

Hi Alexey,

On Thu, Sep 18, 2025 at 10:05:44AM +0200, Alexey Gladkov wrote:
> The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
> get information about builtin modules. Among other information about the module,
> information about module aliases is stored. This is very important to determine
> that a particular modalias will be handled by a module that is inside the
> kernel.
> 
> There are several mechanisms for creating modalias for modules:
> 
> The first is to explicitly specify the MODULE_ALIAS of the macro. In this case,
> the aliases go into the '.modinfo' section of the module if it is compiled
> separately or into vmlinux.o if it is builtin into the kernel.
> 
> The second is the use of MODULE_DEVICE_TABLE followed by the use of the
> modpost utility. In this case, vmlinux.o no longer has this information and
> does not get it into modules.builtin.modinfo.
> 
> For example:
> 
> $ modinfo pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30
> modinfo: ERROR: Module pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 not found.
> 
> $ modinfo xhci_pci
> name:           xhci_pci
> filename:       (builtin)
> license:        GPL
> file:           drivers/usb/host/xhci-pci
> description:    xHCI PCI Host Controller Driver
> 
> The builtin module is missing alias "pci:v*d*sv*sd*bc0Csc03i30*" which will be
> generated by modpost if the module is built separately.
> 
> To fix this it is necessary to add the generated by modpost modalias to
> modules.builtin.modinfo. Fortunately modpost already generates .vmlinux.export.c
> for exported symbols. It is possible to add `.modinfo` for builtin modules and
> modify the build system so that `.modinfo` section is extracted from the
> intermediate vmlinux after modpost is executed.

This seems good to me now. I have tentatively merged this into
kbuild-next so that it can get some more soak testing in -next, as I am
going to be paying less attention to email starting on Sunday for a week
or so, so I would like to be able to deal with regressions promptly.

  https://git.kernel.org/kbuild/l/kbuild-next

Don't consider the commit hashes stable just yet, as I would like to
give Nicolas the chance to provide tags if he would like but I did not
want to wait for the soak testing.

Cheers,
Nathan