Segmentation fault ./scripts/mod/modpost -o vmlinux.symvers vmlinux.o
stops the kernel build. It comes when write_vmlinux_export_c_file()
tries to buf_printf alias->builtin_modname. malloc'ed memory is not
necessarily zeroed. NULL new->builtin_modname before adding to aliases.
Fixes: 5ab23c7923 ("modpost: Create modalias for builtin modules")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/4590a243-0a7e-b7e6-e2d3-cd1b41a12237@google.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
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 <masahiroy@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/28d4da3b0e3fc8474142746bcf469e03752c3208.1758182101.git.legion@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
With the latest binutils, modpost fails with a bus error on some
architectures such as ARM and sparc64.
Since binutils commit 1f1b5e506bf0 ("bfd/ELF: restrict file alignment
for object files"), the byte offset to each section (sh_offset) in
relocatable ELF is no longer guaranteed to be aligned.
modpost parses MODULE_DEVICE_TABLE() data structures, which are usually
located in the .rodata section. If it is not properly aligned, unaligned
access errors may occur.
To address the issue, this commit imports the get_unaligned() helper
from include/linux/unaligned.h.
The get_unaligned_native() helper caters to the endianness in addition
to handling the unaligned access.
I slightly refactored do_pcmcia_entry() and do_input() to avoid writing
back to an unaligned address. (We would need the put_unaligned() helper
to do that.)
The addend_*_rel() functions need similar adjustments because the .text
sections are not aligned either.
It seems that the .symtab, .rel.* and .rela.* sections are still aligned.
Keep normal pointer access for these sections to avoid unnecessary
performance costs.
Reported-by: Paulo Pisati <paolo.pisati@canonical.com>
Reported-by: Matthias Klose <doko@debian.org>
Closes: https://sourceware.org/bugzilla/show_bug.cgi?id=32435
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Closes: https://sourceware.org/bugzilla/show_bug.cgi?id=32493
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Optimize the size of guid_name[], as it only requires 1 additional byte
for '\0' instead of 2.
Simplify the loop by incrementing the iterator by 1 instead of 2.
Remove the unnecessary TO_NATIVE() call, as the guid is represented as
a byte stream.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
This loop should iterate over the range from 'min' to 'max' inclusively.
The last interation is missed.
Fixes: 1d8f430c15 ("[PATCH] Input: add modalias support")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
The first error message in device_id_check() is obscure and can be
misleading because the cause of the error is unlikely to be found in
the struct definition in mod_devicetable.h.
This type of error occurs when an array is passed to an incorrect type
of MODULE_DEVICE_TABLE().
[Example 1]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, foo_ids);
Currently, modpost outputs a meaningless suggestion:
ERROR: modpost: ...: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_device_table__of__<identifier>=64.
Fix definition of struct of_device_id in mod_devicetable.h
The root cause here is that MODULE_DEVICE_TABLE(of, ...) is used instead
of the correct MODULE_DEVICE_TABLE(acpi, ...).
This commit provides a more intuitive error message:
ERROR: modpost: ...: type mismatch between foo_ids[] and MODULE_DEVICE_TABLE(of, ...)
The second error message, related to a missing terminator, is too
verbose.
[Example 2]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
};
MODULE_DEVICE_TABLE(acpi, foo_ids);
The current error message is overly long, and does not pinpoint the
incorrect array:
...: struct acpi_device_id is 32 bytes. The last of 1 is:
0x46 0x4f 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ERROR: modpost: ...: struct acpi_device_id is not terminated with a NULL entry!
This commit changes it to a more concise error message, sufficient to
identify the incorrect array:
ERROR: modpost: ...: foo_ids[] is not terminated with a NULL entry
Lastly, this commit squashes device_id_check() into do_table() and
changes fatal() into error(), allowing modpost to continue processing
other modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This commit renames the alias symbol, __mod_<type>__<name>_device_table
to __mod_device_table__<type>__<name>.
This change simplifies the code slightly, as there is no longer a need
to check both the prefix and suffix.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This commit renames the variables in handle_moddevtable() as follows:
name -> type
namelen -> typelen
identifier -> name
These changes align with the definition in include/linux/module.h:
extern typeof(name) __mod_##type##__##name##_device_table
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
do_usb_table() no longer needs to iterate over the usb_device_id array.
Convert it to a generic ->do_entry() handler.
This is the last special case. Clean up handle_moddevtable().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
do_of_table() no longer needs to iterate over the of_device_id array.
Convert it to a generic ->do_entry() handler.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
do_pnp_device_entry() no longer needs to iterate over the
pnp_device_id array.
Convert it to a generic ->do_entry() handler.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
do_pnp_card_entries() no longer needs to iterate over the
pnp_card_device_id array.
Convert it to a generic ->do_entry() handler.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The do_*_entry() functions cannot check the length of the given buffer.
Use module_alias_printf() helper consistently for these functions.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Replace the first argument with a pointer to struct module.
'filename' can be replaced with mod->name.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
MODULE_DEVICE_TABLE(pnp_card, ...) may have duplicated IDs. For
instance, snd_ad1816a_pnpids[] in sound/isa/ad1816a/ad1816a.c includes
multiple occurrences of the "ADS7180" string within its .devs fields.
Currently, do_pnp_card_entries() handles deduplication on its own, but
this logic should be moved to a common helper function, as drivers in
other subsystems might also have similar duplication issues.
For example, drivers/media/i2c/s5c73m3/s5c73m3.mod.c contains duplicated
MODULE_ALIAS() entries because both s5c73m3-core.c and s5c73m3-spi.c
define the same compatible string.
This commit eliminates redundant MODULE_ALIAS() entries across all
drivers.
[Before]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
[After]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The generic ->do_entry() handler is currently limited to returning
a single alias string.
However, this is not flexible enough for several subsystems, which
currently require their own implementations:
- do_usb_table()
- do_of_table()
- do_pnp_device_entry()
- do_pnp_card_entries()
This commit introduces a helper function so that these special cases can
add multiple MODULE_ALIAS() and then migrate to the generic framework.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The 'id' pointer is never NULL since it has the same address as
'symval'.
Also, checking (*id)[0] is simpler than calling strlen().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This function contains multiple bugs after the following commits:
- ac55182899 ("modpost: i2c aliases need no trailing wildcard")
- 6543becf26 ("mod/file2alias: make modalias generation safe for cross compiling")
Commit ac55182899 inserted the following code to do_eisa_entry():
else
strcat(alias, "*");
This is incorrect because 'alias' is uninitialized. If it is not
NULL-terminated, strcat() could cause a buffer overrun.
Even if 'alias' happens to be zero-filled, it would output:
MODULE_ALIAS("*");
This would match anything. As a result, the module could be loaded by
any unrelated uevent from an unrelated subsystem.
Commit ac55182899 introduced another bug.
Prior to that commit, the conditional check was:
if (eisa->sig[0])
This checked if the first character of eisa_device_id::sig was not '\0'.
However, commit ac55182899 changed it as follows:
if (sig[0])
sig[0] is NOT the first character of the eisa_device_id::sig. The
type of 'sig' is 'char (*)[8]', meaning that the type of 'sig[0]' is
'char [8]' instead of 'char'. 'sig[0]' and 'symval' refer to the same
address, which never becomes NULL.
The correct conversion would have been:
if ((*sig)[0])
However, this if-conditional was meaningless because the earlier change
in commit ac551828993e was incorrect.
This commit removes the entire incorrect code, which should never have
been executed.
Fixes: ac55182899 ("modpost: i2c aliases need no trailing wildcard")
Fixes: 6543becf26 ("mod/file2alias: make modalias generation safe for cross compiling")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When building a 64-bit kernel on a 32-bit build host, incorrect
input MODULE_ALIAS() entries may be generated.
For example, when compiling a 64-bit kernel with CONFIG_INPUT_MOUSEDEV=m
on a 64-bit build machine, you will get the correct output:
$ grep MODULE_ALIAS drivers/input/mousedev.mod.c
MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*r*0,*1,*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*r*a*0,*1,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*r*a*0,*1,*18,*1C,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*r*a*0,*1,*m*l*s*f*w*");
However, building the same kernel on a 32-bit machine results in
incorrect output:
$ grep MODULE_ALIAS drivers/input/mousedev.mod.c
MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*130,*r*0,*1,*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*16A,*r*a*0,*1,*20,*21,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*165,*r*a*0,*1,*18,*1C,*20,*21,*38,*3C,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*130,*r*a*0,*1,*20,*21,*m*l*s*f*w*");
A similar issue occurs with CONFIG_INPUT_JOYDEV=m. On a 64-bit build
machine, the output is:
$ grep MODULE_ALIAS drivers/input/joydev.mod.c
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*120,*r*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*130,*r*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*r*a*m*l*s*f*w*");
However, on a 32-bit machine, the output is incorrect:
$ grep MODULE_ALIAS drivers/input/joydev.mod.c
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*20,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*22,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*28,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*26,*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*");
MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*2E0,*r*a*m*l*s*f*w*");
When building a 64-bit kernel, BITS_PER_LONG is defined as 64. However,
on a 32-bit build machine, the constant 1L is a signed 32-bit value.
Left-shifting it beyond 32 bits causes wraparound, and shifting by 31
or 63 bits makes it a negative value.
The fix in commit e0e9263271 ("[PATCH] PATCH: 1 line 2.6.18 bugfix:
modpost-64bit-fix.patch") is incorrect; it only addresses cases where
a 64-bit kernel is built on a 64-bit build machine, overlooking cases
on a 32-bit build machine.
Using 1ULL ensures a 64-bit width on both 32-bit and 64-bit machines,
avoiding the wraparound issue.
Fixes: e0e9263271 ("[PATCH] PATCH: 1 line 2.6.18 bugfix: modpost-64bit-fix.patch")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When CONFIG_SATA_AHCI_PLATFORM=m, modpost outputs incorect acpi
MODULE_ALIAS() if the endianness of the target and the build machine
do not match.
When the endianness of the target kernel and the build machine match,
the output is correct:
$ grep 'MODULE_ALIAS("acpi' drivers/ata/ahci_platform.mod.c
MODULE_ALIAS("acpi*:APMC0D33:*");
MODULE_ALIAS("acpi*:010601:*");
However, when building a little-endian kernel on a big-endian machine
(or vice versa), the output is incorrect:
$ grep 'MODULE_ALIAS("acpi' drivers/ata/ahci_platform.mod.c
MODULE_ALIAS("acpi*:APMC0D33:*");
MODULE_ALIAS("acpi*:0601??:*");
The 'cls' and 'cls_msk' fields are 32-bit.
DEF_FIELD() must be used instead of DEF_FIELD_ADDR() to correctly handle
endianness of these 32-bit fields.
The check 'if (cls)' was unnecessary; it never became NULL, as it was
the pointer to 'symval' plus the offset to the 'cls' field.
Fixes: 26095a01d3 ("ACPI / scan: Add support for ACPI _CLS device matching")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Hugh Dickins
Alexey Gladkov
Greg Kroah-Hartman
Masahiro Yamada
Abhishek Pandit-Subedi