kernel/linux.git/scripts/mod/modpost.c, branch v6.18.21

modpost: Amend ppc64 save/restfpr symnames for -Os build

2026-03-04T12:20:07+00:00

[ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

modpost: Create modalias for builtin modules

2025-09-24T16:10:45+00:00

For some modules, modalias is generated using the modpost utility and the section is added to the module file. When a module is added inside vmlinux, modpost does not generate modalias for such modules and the information is lost. As a result kmod (which uses modules.builtin.modinfo in userspace) cannot determine that modalias is handled by a builtin kernel module. $ cat /sys/devices/pci0000:00/0000:00:14.0/modalias pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 $ modinfo xhci_pci name: xhci_pci filename: (builtin) license: GPL file: drivers/usb/host/xhci-pci description: xHCI PCI Host Controller Driver Missing modalias "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 generate the same modalias for vmlinux as for the individual modules. Fortunately '.vmlinux.export.o' is already generated from which '.modinfo' can be extracted in the same way as for vmlinux.o. Signed-off-by: Masahiro Yamada Signed-off-by: Alexey Gladkov Tested-by: Stephen Rothwell Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/28d4da3b0e3fc8474142746bcf469e03752c3208.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor

modpost: check forbidden MODULE_IMPORT_NS("module:") at compile time

2025-05-25T09:15:51+00:00

Explicitly adding MODULE_IMPORT_NS("module:...") is not allowed. Currently, this is only checked at run time. That is, when such a module is loaded, an error message like the following is shown: foo: module tries to import module namespace: module:bar Obviously, checking this at compile time improves usability. In such a case, modpost will report the following error at compile time: ERROR: modpost: foo: explicitly importing namespace "module:bar" is not allowed. Signed-off-by: Masahiro Yamada

module: Extend the module namespace parsing

2025-05-25T09:12:03+00:00

Instead of only accepting "module:${name}", extend it with a comma separated list of module names and add tail glob support. That is, something like: "module:foo-*,bar" is now possible. Signed-off-by: Peter Zijlstra Reviewed-by: Petr Pavlu Signed-off-by: Masahiro Yamada

module: Add module specific symbol namespace support

2025-05-25T09:11:56+00:00

Designate the "module:${modname}" symbol namespace to mean: 'only export to the named module'. Notably, explicit imports of anything in the "module:" space is forbidden. Signed-off-by: Peter Zijlstra Reviewed-by: Petr Pavlu Signed-off-by: Masahiro Yamada

modpost: Use for() loop

2025-05-25T09:00:52+00:00

Slight cleanup by using a for() loop instead of while(). This makes it clearer what is the iteration and what is the actual work done. Signed-off-by: Peter Zijlstra Signed-off-by: Masahiro Yamada

Disable SLUB_TINY for build testing

2025-04-06T17:00:04+00:00

... and don't error out so hard on missing module descriptions. Before commit 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") we used to warn about missing module descriptions, but only when building with extra warnigns (ie 'W=1'). After that commit the warning became an unconditional hard error. And it turns out not all modules have been converted despite the claims to the contrary. As reported by Damian Tometzki, the slub KUnit test didn't have a module description, and apparently nobody ever really noticed. The reason nobody noticed seems to be that the slub KUnit tests get disabled by SLUB_TINY, which also ends up disabling a lot of other code, both in tests and in slub itself. And so anybody doing full build tests didn't actually see this failre. So let's disable SLUB_TINY for build-only tests, since it clearly ends up limiting build coverage. Also turn the missing module descriptions error back into a warning, but let's keep it around for non-'W=1' builds. Reported-by: Damian Tometzki Link: https://lore.kernel.org/all/01070196099fd059-e8463438-7b1b-4ec8-816d-173874be9966-000000@eu-central-1.amazonses.com/ Cc: Masahiro Yamada Cc: Jeff Johnson Fixes: 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") Signed-off-by: Linus Torvalds

modpost: require a MODULE_DESCRIPTION()

2025-03-22T15:56:12+00:00

Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the description is missing"), a module without a MODULE_DESCRIPTION() has resulted in a warning with make W=1. Since that time, all known instances of this issue have been fixed. Therefore, now make it an error if a MODULE_DESCRIPTION() is not present. Signed-off-by: Jeff Johnson Signed-off-by: Masahiro Yamada

modpost: introduce get_basename() helper

2025-03-15T12:16:21+00:00

The logic to retrieve the basename appears multiple times. Factor out the common pattern into a helper function. I copied kbasename() from include/linux/string.h and renamed it to get_basename(). Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier

modpost: Fix a few typos in a comment

2025-02-15T18:10:58+00:00

Namely: s/becasue/because/ and s/wiht/with/ plus an added article. Signed-off-by: Uwe Kleine-König Signed-off-by: Masahiro Yamada