summaryrefslogtreecommitdiff
path: root/scripts/mod/modpost.c
AgeCommit message (Collapse)Author
2022-05-08modpost: make multiple export errorMasahiro Yamada
This is currently a warning, but I think modpost should stop building in this case. If the same symbol is exported multiple times and we let it keep going, the sanity check becomes difficult. Only the legitimate case is that an external module overrides the corresponding in-tree module to provide a different implementation with the same interface. Also, there exists an upstream example that exploits this feature. $ make M=tools/testing/nvdimm ... builds tools/testing/nvdimm/libnvdimm.ko. This is a mocked module that overrides the symbols from drivers/nvdimm/libnvdimm.ko. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: dump Module.symvers in the same order of modules.orderMasahiro Yamada
modpost dumps the exported symbols into Module.symvers, but currently in random order because it iterates in the hash table. Add a linked list of exported symbols in struct module, so we can iterate on symbols per module. This commit makes Module.symvers much more readable; the outer loop in write_dump() iterates over the modules in the order of modules.order, and the inner loop dumps symbols in each module. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: traverse the namespace_list in orderMasahiro Yamada
Use the doubly linked list to traverse the list in the added order. This makes the code more consistent. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: use doubly linked list for dump_listsMasahiro Yamada
This looks easier to understand (just because this is a pattern in the kernel code). No functional change is intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: traverse unresolved symbols in orderMasahiro Yamada
Currently, modpost manages unresolved in a singly linked list; it adds a new node to the head, and traverses the list from new to old. Use a doubly linked list to keep the order in the symbol table in the ELF file. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: add sym_add_unresolved() helperMasahiro Yamada
Add a small helper, sym_add_unresolved() to ease the further refactoring. Remove the 'weak' argument from alloc_symbol() because it is sensible only for unresolved symbols. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: traverse modules in orderMasahiro Yamada
Currently, modpost manages modules in a singly linked list; it adds a new node to the head, and traverses the list from new to old. It works, but the error messages are shown in the reverse order. If you have a Makefile like this: obj-m += foo.o bar.o then, modpost shows error messages in bar.o, foo.o, in this order. Use a doubly linked list to keep the order in modules.order; use list_add_tail() for the node addition and list_for_each_entry() for the list traverse. Now that the kernel's list macros have been imported to modpost, I will use them actively going forward. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: change mod->gpl_compatible to bool typeMasahiro Yamada
Currently, mod->gpl_compatible is tristate; it is set to -1 by default, then to 1 or 0 when MODULE_LICENSE() is found. Maybe, -1 was chosen to represent the 'unknown' license, but it is not useful. The current code: if (!mod->gpl_compatible) check_for_gpl_usage(exp->export, basename, exp->name); ... only cares whether gpl_compatible is zero or not. Change it to a bool type with the initial value 'true', which has no functional change. The default value should be 'true' instead of 'false'. Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE() into error"), unknown module license is an error. The error message, "missing MODULE_LICENSE()" is enough to explain the issue. It is not sensible to show another message, "GPL-incompatible module ... uses GPL-only symbol". Add comments to explain this. While I was here, I renamed gpl_compatible to is_gpl_compatible for clarification, and also slightly refactored the code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: use bool type where appropriateMasahiro Yamada
Use 'bool' to clarify that the valid value is true or false. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: move struct namespace_list to modpost.cMasahiro Yamada
There is no good reason to define struct namespace_list in modpost.h struct module has pointers to struct namespace_list, but that does not require the definition of struct namespace_list. Move it to modpost.c. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: retrieve the module dependency and CRCs in check_exports()Masahiro Yamada
Do not repeat the similar code. It is simpler to do this in check_exports() instead of add_versions(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: add a separate error for exported symbols without definitionMasahiro Yamada
It took me a while to understand the intent of "exp->module == mod". This code goes back to 2003. [1] The commit is not in this git repository, and might be worth a little explanation. You can add EXPORT_SYMBOL() without having its definition in the same file (but you need to put a declaration). This is typical when EXPORT_SYMBOL() is added in a C file, but the actual implementation is in a separate assembly file. One example is arch/arm/kernel/armksyms.c In the old days, EXPORT_SYMBOL() was only available in C files (but this limitation does not exist any more). If you forget to add the definition, this error occurs. Add a separate, clearer message for this case. It should be an error even if KBUILD_MODPOST_WARN is given. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=2763b6bcb96e6a38a2fe31108fe5759ec5bcc80a Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: remove stale comment about sym_add_exported()Masahiro Yamada
The description, it may have already been added without a CRC, in this case just update the CRC ... is no longer valid. In the old days, this function was used to update the CRC as well. Commit 040fcc819a2e ("kbuild: improved modversioning support for external modules") started to use a separate function (sym_update_crc) for updating the CRC. The first part, "Add an exported symbol" is correct, but it is too obvious from the function name. Drop this comment entirely. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: do not write out any file when error occurredMasahiro Yamada
If an error occurs, modpost will fail anyway. Do not write out any content (, which might be invalid). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: use snprintf() instead of sprintf() for safetyMasahiro Yamada
Use snprintf() to avoid the potential buffer overflow, and also check the return value to detect the too long path. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: remove annoying namespace_from_kstrtabns()Masahiro Yamada
There are two call sites for sym_update_namespace(). When the symbol has no namespace, s->namespace is set to NULL, but the conversion from "" to NULL is done in two different places. [1] read_symbols() This gets the namespace from __kstrtabns_<symbol>. If the symbol has no namespace, sym_get_data(info, sym) returns the empty string "". namespace_from_kstrtabns() converts it to NULL before it is passed to sym_update_namespace(). [2] read_dump() This gets the namespace from the dump file, *.symvers. If the symbol has no namespace, the 'namespace' is the empty string "", which is directly passed into sym_update_namespace(). The conversion from "" to NULL is done in sym_update_namespace(). namespace_from_kstrtabns() exists only for creating this inconsistency. Remove namespace_from_kstrtabns() so that sym_update_namespace() is consistently passed with "" instead of NULL. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: remove redundant initializes for static variablesMasahiro Yamada
These are initialized with zeros without explicit initializers. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: move export_from_secname() call to more relevant placeMasahiro Yamada
The assigned 'export' is only used when if (strstarts(symname, "__ksymtab_")) is met. The else-part of the assignment is the dead code. Move the export_from_secname() call to where it is used. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-05-08modpost: remove useless export_from_sec()Masahiro Yamada
With commit 1743694eb235 ("modpost: stop symbol preloading for modversion CRC") applied, now export_from_sec() is useless. handle_symbol() is called for every symbol in the ELF. When 'symname' does not start with "__ksymtab", export_from_sec() is called, and the returned value is stored in 'export'. It is used in the last part of handle_symbol(): if (strstarts(symname, "__ksymtab_")) { name = symname + strlen("__ksymtab_"); sym_add_exported(name, mod, export); } 'export' is used only when 'symname' starts with "__ksymtab_". So, the value returned by export_from_sec() is never used. Remove useless export_from_sec(). This makes further cleanups possible. I put the temporary code: export = export_unknown; Otherwise, I would get the compiler warning: warning: 'export' may be used uninitialized in this function [-Wmaybe-uninitialized] This is apparently false positive because if (strstarts(symname, "__ksymtab_") ... is a stronger condition than: if (strstarts(symname, "__ksymtab") Anyway, this part will be cleaned up by the next commit. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-04-03modpost: restore the warning message for missing symbol versionsMasahiro Yamada
This log message was accidentally chopped off. I was wondering why this happened, but checking the ML log, Mark precisely followed my suggestion [1]. I just used "..." because I was too lazy to type the sentence fully. Sorry for the confusion. [1]: https://lore.kernel.org/all/CAK7LNAR6bXXk9-ZzZYpTqzFqdYbQsZHmiWspu27rtsFxvfRuVA@mail.gmail.com/ Fixes: 4a6795933a89 ("kbuild: modpost: Explicitly warn about unprototyped symbols") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-27Merge tag 'x86_core_for_5.18_rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 CET-IBT (Control-Flow-Integrity) support from Peter Zijlstra: "Add support for Intel CET-IBT, available since Tigerlake (11th gen), which is a coarse grained, hardware based, forward edge Control-Flow-Integrity mechanism where any indirect CALL/JMP must target an ENDBR instruction or suffer #CP. Additionally, since Alderlake (12th gen)/Sapphire-Rapids, speculation is limited to 2 instructions (and typically fewer) on branch targets not starting with ENDBR. CET-IBT also limits speculation of the next sequential instruction after the indirect CALL/JMP [1]. CET-IBT is fundamentally incompatible with retpolines, but provides, as described above, speculation limits itself" [1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html * tag 'x86_core_for_5.18_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (53 commits) kvm/emulate: Fix SETcc emulation for ENDBR x86/Kconfig: Only allow CONFIG_X86_KERNEL_IBT with ld.lld >= 14.0.0 x86/Kconfig: Only enable CONFIG_CC_HAS_IBT for clang >= 14.0.0 kbuild: Fixup the IBT kbuild changes x86/Kconfig: Do not allow CONFIG_X86_X32_ABI=y with llvm-objcopy x86: Remove toolchain check for X32 ABI capability x86/alternative: Use .ibt_endbr_seal to seal indirect calls objtool: Find unused ENDBR instructions objtool: Validate IBT assumptions objtool: Add IBT/ENDBR decoding objtool: Read the NOENDBR annotation x86: Annotate idtentry_df() x86,objtool: Move the ASM_REACHABLE annotation to objtool.h x86: Annotate call_on_stack() objtool: Rework ASM_REACHABLE x86: Mark __invalid_creds() __noreturn exit: Mark do_group_exit() __noreturn x86: Mark stop_this_cpu() __noreturn objtool: Ignore extra-symbol code objtool: Rename --duplicate to --lto ...
2022-03-25Merge tag 'kbuild-gnu11-v5.18' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild update for C11 language base from Masahiro Yamada: "Kbuild -std=gnu11 updates for v5.18 Linus pointed out the benefits of C99 some years ago, especially variable declarations in loops [1]. At that time, we were not ready for the migration due to old compilers. Recently, Jakob Koschel reported a bug in list_for_each_entry(), which leaks the invalid pointer out of the loop [2]. In the discussion, we agreed that the time had come. Now that GCC 5.1 is the minimum compiler version, there is nothing to prevent us from going to -std=gnu99, or even straight to -std=gnu11. Discussions for a better list iterator implementation are ongoing, but this patch set must land first" [1] https://lore.kernel.org/all/CAHk-=wgr12JkKmRd21qh-se-_Gs69kbPgR9x4C+Es-yJV2GLkA@mail.gmail.com/ [2] https://lore.kernel.org/lkml/86C4CE7D-6D93-456B-AA82-F8ADEACA40B7@gmail.com/ * tag 'kbuild-gnu11-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: Kbuild: use -std=gnu11 for KBUILD_USERCFLAGS Kbuild: move to -std=gnu11 Kbuild: use -Wdeclaration-after-statement Kbuild: add -Wno-shift-negative-value where -Wextra is used
2022-03-22kbuild: Fixup the IBT kbuild changesPeter Zijlstra
Masahiro-san deemed my kbuild changes to support whole module objtool runs too terrible to live and gracefully provided an alternative. Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/CAK7LNAQ2mYMnOKMQheVi+6byUFE3KEkjm1zcndNUfe0tORGvug@mail.gmail.com
2022-03-13Kbuild: use -Wdeclaration-after-statementMark Rutland
The kernel is moving from using `-std=gnu89` to `-std=gnu11`, permitting the use of additional C11 features such as for-loop initial declarations. One contentious aspect of C99 is that it permits mixed declarations and code, and for now at least, it seems preferable to enforce that declarations must come first. These warnings were already enabled in the kernel itself, but not for KBUILD_USERCFLAGS or the compat VDSO on arch/arm64, which uses a separate set of CFLAGS. This patch fixes an existing violation in modpost.c, which is not reported because of the missing flag in KBUILD_USERCFLAGS: | scripts/mod/modpost.c: In function ‘match’: | scripts/mod/modpost.c:837:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] | 837 | const char *endp = p + strlen(p) - 1; | | ^~~~~ Signed-off-by: Mark Rutland <mark.rutland@arm.com> [arnd: don't add a duplicate flag to the default set, update changelog] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 (x86-64) Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-10s390/nospec: add an option to use thunk-externVasily Gorbik
Currently with -mindirect-branch=thunk and -mfunction-return=thunk compiler options expoline thunks are put into individual COMDAT group sections. s390 is the only architecture which has group sections and it has implications for kpatch and objtool tools support. Using -mindirect-branch=thunk-extern and -mfunction-return=thunk-extern is an alternative, which comes with a need to generate all required expoline thunks manually. Unfortunately modules area is too far away from the kernel image, and expolines from the kernel image cannon be used. But since all new distributions (except Debian) build kernels for machine generations newer than z10, where "exrl" instruction is available, that leaves only 16 expolines thunks possible. Provide an option to build the kernel with -mindirect-branch=thunk-extern and -mfunction-return=thunk-extern for z10 or newer. This also requires to postlink expoline thunks into all modules explicitly. Currently modules already contain most expolines anyhow. Unfortunately -mindirect-branch=thunk-extern and -mfunction-return=thunk-extern options support is broken in gcc <= 11.2. Additional compile test is required to verify proper gcc support. Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Co-developed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2022-01-05riscv: switch to relative exception tablesJisheng Zhang
Similar as other architectures such as arm64, x86 and so on, use offsets relative to the exception table entry values rather than absolute addresses for both the exception locationand the fixup. However, RISCV label difference will actually produce two relocations, a pair of R_RISCV_ADD32 and R_RISCV_SUB32. Take below simple code for example: $ cat test.S .section .text 1: nop .section __ex_table,"a" .balign 4 .long (1b - .) .previous $ riscv64-linux-gnu-gcc -c test.S $ riscv64-linux-gnu-readelf -r test.o Relocation section '.rela__ex_table' at offset 0x100 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000600000023 R_RISCV_ADD32 0000000000000000 .L1^B1 + 0 000000000000 000500000027 R_RISCV_SUB32 0000000000000000 .L0 + 0 The modpost will complain the R_RISCV_SUB32 relocation, so we need to patch modpost.c to skip this relocation for .rela__ex_table section. After this patch, the __ex_table section size of defconfig vmlinux is reduced from 7072 Bytes to 3536 Bytes. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-09-03Merge tag 'kbuild-v5.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add -s option (strict mode) to merge_config.sh to make it fail when any symbol is redefined. - Show a warning if a different compiler is used for building external modules. - Infer --target from ARCH for CC=clang to let you cross-compile the kernel without CROSS_COMPILE. - Make the integrated assembler default (LLVM_IAS=1) for CC=clang. - Add <linux/stdarg.h> to the kernel source instead of borrowing <stdarg.h> from the compiler. - Add Nick Desaulniers as a Kbuild reviewer. - Drop stale cc-option tests. - Fix the combination of CONFIG_TRIM_UNUSED_KSYMS and CONFIG_LTO_CLANG to handle symbols in inline assembly. - Show a warning if 'FORCE' is missing for if_changed rules. - Various cleanups * tag 'kbuild-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits) kbuild: redo fake deps at include/ksym/*.h kbuild: clean up objtool_args slightly modpost: get the *.mod file path more simply checkkconfigsymbols.py: Fix the '--ignore' option kbuild: merge vmlinux_link() between ARCH=um and other architectures kbuild: do not remove 'linux' link in scripts/link-vmlinux.sh kbuild: merge vmlinux_link() between the ordinary link and Clang LTO kbuild: remove stale *.symversions kbuild: remove unused quiet_cmd_update_lto_symversions gen_compile_commands: extract compiler command from a series of commands x86: remove cc-option-yn test for -mtune= arc: replace cc-option-yn uses with cc-option s390: replace cc-option-yn uses with cc-option ia64: move core-y in arch/ia64/Makefile to arch/ia64/Kbuild sparc: move the install rule to arch/sparc/Makefile security: remove unneeded subdir-$(CONFIG_...) kbuild: sh: remove unused install script kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y kbuild: Switch to 'f' variants of integrated assembler flag kbuild: Shuffle blank line to improve comment meaning ...
2021-09-03modpost: get the *.mod file path more simplyMasahiro Yamada
get_src_version() strips 'o' or 'lto.o' from the end of the object file path (so, postfixlen is 1 or 5), then adds 'mod'. If you look at the code closely, mod->name already holds the base path with the extension stripped. Most of the code changes made by commit 7ac204b545f2 ("modpost: lto: strip .lto from module names") was actually unneeded. sumversion.c does not need strends(), so it can get back local in modpost.c again. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-15powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm gotoChristophe Leroy
Using asm goto in __WARN_FLAGS() and WARN_ON() allows more flexibility to GCC. For that add an entry to the exception table so that program_check_exception() knowns where to resume execution after a WARNING. Here are two exemples. The first one is done on PPC32 (which benefits from the previous patch), the second is on PPC64. unsigned long test(struct pt_regs *regs) { int ret; WARN_ON(regs->msr & MSR_PR); return regs->gpr[3]; } unsigned long test9w(unsigned long a, unsigned long b) { if (WARN_ON(!b)) return 0; return a / b; } Before the patch: 000003a8 <test>: 3a8: 81 23 00 84 lwz r9,132(r3) 3ac: 71 29 40 00 andi. r9,r9,16384 3b0: 40 82 00 0c bne 3bc <test+0x14> 3b4: 80 63 00 0c lwz r3,12(r3) 3b8: 4e 80 00 20 blr 3bc: 0f e0 00 00 twui r0,0 3c0: 80 63 00 0c lwz r3,12(r3) 3c4: 4e 80 00 20 blr 0000000000000bf0 <.test9w>: bf0: 7c 89 00 74 cntlzd r9,r4 bf4: 79 29 d1 82 rldicl r9,r9,58,6 bf8: 0b 09 00 00 tdnei r9,0 bfc: 2c 24 00 00 cmpdi r4,0 c00: 41 82 00 0c beq c0c <.test9w+0x1c> c04: 7c 63 23 92 divdu r3,r3,r4 c08: 4e 80 00 20 blr c0c: 38 60 00 00 li r3,0 c10: 4e 80 00 20 blr After the patch: 000003a8 <test>: 3a8: 81 23 00 84 lwz r9,132(r3) 3ac: 71 29 40 00 andi. r9,r9,16384 3b0: 40 82 00 0c bne 3bc <test+0x14> 3b4: 80 63 00 0c lwz r3,12(r3) 3b8: 4e 80 00 20 blr 3bc: 0f e0 00 00 twui r0,0 0000000000000c50 <.test9w>: c50: 7c 89 00 74 cntlzd r9,r4 c54: 79 29 d1 82 rldicl r9,r9,58,6 c58: 0b 09 00 00 tdnei r9,0 c5c: 7c 63 23 92 divdu r3,r3,r4 c60: 4e 80 00 20 blr c70: 38 60 00 00 li r3,0 c74: 4e 80 00 20 blr In the first exemple, we see GCC doesn't need to duplicate what happens after the trap. In the second exemple, we see that GCC doesn't need to emit a test and a branch in the likely path in addition to the trap. We've got some WARN_ON() in .softirqentry.text section so it needs to be added in the OTHER_TEXT_SECTIONS in modpost.c Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/389962b1b702e3c78d169e59bcfac56282889173.1618331882.git.christophe.leroy@csgroup.eu
2021-06-17kbuild: modpost: Explicitly warn about unprototyped symbolsMark Brown
One common cause of modpost version generation failures is a failure to prototype exported assembly functions - the tooling requires this for exported functions even if they are not and should not be called from C code in order to do the version mangling for symbols. Unfortunately the error message is currently rather abstruse, simply saying that "version generation failed" and even diving into the code doesn't directly show what's going on since there's several steps between the problem and it being observed. Provide an explicit hint as to the likely cause of a version generation failure to help anyone who runs into this in future more readily diagnose and fix the problem. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: add an elfnote for whether vmlinux is built with ltoYonghong Song
Currently, clang LTO built vmlinux won't work with pahole. LTO introduced cross-cu dwarf tag references and broke current pahole model which handles one cu as a time. The solution is to merge all cu's as one pahole cu as in [1]. We would like to do this merging only if cross-cu dwarf references happens. The LTO build mode is a pretty good indication for that. In earlier version of this patch ([2]), clang flag -grecord-gcc-switches is proposed to add to compilation flags so pahole could detect "-flto" and then merging cu's. This will increate the binary size of 1% without LTO though. Arnaldo suggested to use a note to indicate the vmlinux is built with LTO. Such a cheap way to get whether the vmlinux is built with LTO or not helps pahole but is also useful for tracing as LTO may inline/delete/demote global functions, promote static functions, etc. So this patch added an elfnote with a new type LINUX_ELFNOTE_LTO_INFO. The owner of the note is "Linux". With gcc 8.4.1 and clang trunk, without LTO, I got $ readelf -n vmlinux Displaying notes found in: .notes Owner Data size Description ... Linux 0x00000004 func description data: 00 00 00 00 ... With "readelf -x ".notes" vmlinux", I can verify the above "func" with type code 0x101. With clang thin-LTO, I got the same as above except the following: description data: 01 00 00 00 which indicates the vmlinux is built with LTO. [1] https://lore.kernel.org/bpf/20210325065316.3121287-1-yhs@fb.com/ [2] https://lore.kernel.org/bpf/20210331001623.2778934-1-yhs@fb.com/ Suggested-by: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> Signed-off-by: Yonghong Song <yhs@fb.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc4 (x86-64) Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25scripts: modpost.c: Fix a few typosBhaskar Chowdhury
s/agorithm/algorithm/ s/criterias/criteria/ s/targetting/targeting/ ....two different places. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: fix false-positive modpost warning when all symbols are trimmedMasahiro Yamada
Nathan reports that the mips defconfig emits the following warning: WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol check will be entirely skipped. This false-positive happens when CONFIG_TRIM_UNUSED_KSYMS is enabled, but no CONFIG option is set to 'm'. Commit a0590473c5e6 ("nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default") turned the last 'm' into 'y' for the mips defconfig, and uncovered this issue. In this case, the module feature itself is enabled, but we have no module to build. As a result, CONFIG_TRIM_UNUSED_KSYMS drops all the instances of EXPORT_SYMBOL. Then, modpost wrongly assumes vmlinux is missing because vmlinux.symvers is empty. (As another false-positive case, you can create a module that does not use any symbol of vmlinux). The current behavior is to entirely suppress the unresolved symbol warnings when vmlinux is missing just because there are too many. I found the origin of this code in the historical git tree. [1] If this is a matter of noisiness, I think modpost can display the first 10 warnings, and the number of suppressed warnings at the end. You will get a bit noisier logs when you run 'make modules' without vmlinux, but such warnings are better to show because you never know the resulting modules are actually loadable or not. This commit changes the following: - If any of input *.symver files is missing, pass -w option to let the module build keep going with warnings instead of errors. - If there are too many (10+) unresolved symbol warnings, show only the first 10, and also the number of suppressed warnings. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=1cc0e0529569bf6a94f6d49770aa6d4b599d2c46 Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: generate Module.symvers only when vmlinux existsMasahiro Yamada
The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-02-23Merge tag 'modules-for-v5.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull module updates from Jessica Yu: - Retire EXPORT_UNUSED_SYMBOL() and EXPORT_SYMBOL_GPL_FUTURE(). These export types were introduced between 2006 - 2008. All the of the unused symbols have been long removed and gpl future symbols were converted to gpl quite a long time ago, and I don't believe these export types have been used ever since. So, I think it should be safe to retire those export types now (Christoph Hellwig) - Refactor and clean up some aged code cruft in the module loader (Christoph Hellwig) - Build {,module_}kallsyms_on_each_symbol only when livepatching is enabled, as it is the only caller (Christoph Hellwig) - Unexport find_module() and module_mutex and fix the last module callers to not rely on these anymore. Make module_mutex internal to the module loader (Christoph Hellwig) - Harden ELF checks on module load and validate ELF structures before checking the module signature (Frank van der Linden) - Fix undefined symbol warning for clang (Fangrui Song) - Fix smatch warning (Dan Carpenter) * tag 'modules-for-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: module: potential uninitialized return in module_kallsyms_on_each_symbol() module: remove EXPORT_UNUSED_SYMBOL* module: remove EXPORT_SYMBOL_GPL_FUTURE module: move struct symsearch to module.c module: pass struct find_symbol_args to find_symbol module: merge each_symbol_section into find_symbol module: remove each_symbol_in_section module: mark module_mutex static kallsyms: only build {,module_}kallsyms_on_each_symbol when required kallsyms: refactor {,module_}kallsyms_on_each_symbol module: use RCU to synchronize find_module module: unexport find_module and module_mutex drm: remove drm_fb_helper_modinit powerpc/powernv: remove get_cxl_module module: harden ELF info handling module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols
2021-02-08module: remove EXPORT_UNUSED_SYMBOL*Christoph Hellwig
EXPORT_UNUSED_SYMBOL* is not actually used anywhere. Remove the unused functionality as we generally just remove unused code anyway. Reviewed-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2021-02-08module: remove EXPORT_SYMBOL_GPL_FUTUREChristoph Hellwig
As far as I can tell this has never been used at all, and certainly not any time recently. Reviewed-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2021-01-14modpost: lto: strip .lto from module namesSami Tolvanen
With LTO, everything is compiled into LLVM bitcode, so we have to link each module into native code before modpost. Kbuild uses the .lto.o suffix for these files, which also ends up in module information. This change strips the unnecessary .lto suffix from the module name. Suggested-by: Bill Wendling <morbo@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-11-samitolvanen@google.com
2020-12-21modpost: turn static exports into errorQuentin Perret
Using EXPORT_SYMBOL*() on static functions is fundamentally wrong. Modpost currently reports that as a warning, but clearly this is not a pattern we should allow, and all in-tree occurences should have been fixed by now. So, promote the warn() message to error() to make sure this never happens again. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Matthias Maennich <maennich@google.com> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-12-21modpost: turn section mismatches to error from fatal()Masahiro Yamada
There is code that reports static EXPORT_SYMBOL a few lines below. It is not a good idea to bail out here. I renamed sec_mismatch_fatal to sec_mismatch_warn_only (with logical inversion) to match to CONFIG_SECTION_MISMATCH_WARN_ONLY. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-12-21modpost: change license incompatibility to error() from fatal()Masahiro Yamada
Change fatal() to error() to continue running to report more possible issues. There is no difference in the fact that modpost will fail anyway. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-12-21modpost: turn missing MODULE_LICENSE() into errorMasahiro Yamada
Do not create modules with no license tag. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-12-21modpost: refactor error handling and clarify error/fatal differenceMasahiro Yamada
We have 3 log functions. fatal() is special because it lets modpost bail out immediately. The difference between warn() and error() is the only prefix parts ("WARNING:" vs "ERROR:"). In my understanding, the expected handling of error() is to propagate the return code of the function to the exit code of modpost, as check_exports() etc. already does. This is a good manner in general because we should display as many error messages as possible in a single run of modpost. What is annoying about fatal() is that it kills modpost at the first error. People would need to run Kbuild again and again until they fix all errors. But, unfortunately, people tend to do: "This case should not be allowed. Let's replace warn() with fatal()." One of the reasons is probably it is tedious to manually hoist the error code to the main() function. This commit refactors error() so any single call for it automatically makes modpost return the error code. I also added comments in modpost.h for warn(), error(), and fatal(). Please use fatal() only when you have a strong reason to do so. For example: - Memory shortage (i.e. malloc() etc. has failed) - The ELF file is broken, and there is no point to continue parsing - Something really odd has happened For general coding errors, please use error(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Quentin Perret <qperret@google.com>
2020-12-21modpost: rename merror() to error()Masahiro Yamada
The log function names, warn(), merror(), fatal() are inconsistent. Commit 2a11665945d5 ("kbuild: distinguish between errors and warnings in modpost") intentionally chose merror() to avoid the conflict with the library function error(). See man page of error(3). But, we are already causing the conflict with warn() because it is also a library function. See man page of warn(3). err() would be a problem for the same reason. The common technique to work around name conflicts is to use macros. For example: /* in a header */ #define error(fmt, ...) __error(fmt, ##__VA_ARGS__) #define warn(fmt, ...) __warn(fmt, ##__VA_ARGS__) /* function definition */ void __error(const char *fmt, ...) { <our implementation> } void __warn(const char *fmt, ...) { <our implementation> } In this way, we can implement our own warn() and error(), still we can include <error.h> and <err.h> with no problem. And, commit 93c95e526a4e ("modpost: rework and consolidate logging interface") already did that. Since the log functions are all macros, we can use error() without causing "conflicting types" errors. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-10-25treewide: Convert macro and uses of __section(foo) to __section("foo")Joe Perches
Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Conversion done using the script at: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl Signed-off-by: Joe Perches <joe@perches.com> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-07-27modpost: explain why we can't use strsepWolfram Sang
Mention why we open-code strsep, so it is clear that it is intentional. Fixes: 736bb11898ef ("modpost: remove use of non-standard strsep() in HOSTCC code") Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-07-07modpost: remove use of non-standard strsep() in HOSTCC codeH. Nikolaus Schaller
strsep() is neither standard C nor POSIX and used outside the kernel code here. Using it here requires that the build host supports it out of the box which is e.g. not true for a Darwin build host and using a cross-compiler. This leads to: scripts/mod/modpost.c:145:2: warning: implicit declaration of function 'strsep' [-Wimplicit-function-declaration] return strsep(stringp, "\n"); ^ and a segfault when running MODPOST. See also: https://stackoverflow.com/a/7219504 So let's replace this by strchr() instead of using strsep(). It does not hurt kernel size or speed since this code is run on the build host. Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line() helpers") Co-developed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-06Merge tag 'kbuild-v5.8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - fix warnings in 'make clean' for ARCH=um, hexagon, h8300, unicore32 - ensure to rebuild all objects when the compiler is upgraded - exclude system headers from dependency tracking and fixdep processing - fix potential bit-size mismatch between the kernel and BPF user-mode helper - add the new syntax 'userprogs' to build user-space programs for the target architecture (the same arch as the kernel) - compile user-space sample code under samples/ for the target arch instead of the host arch - make headers_install fail if a CONFIG option is leaked to user-space - sanitize the output format of scripts/checkstack.pl - handle ARM 'push' instruction in scripts/checkstack.pl - error out before modpost if a module name conflict is found - error out when multiple directories are passed to M= because this feature is broken for a long time - add CONFIG_DEBUG_INFO_COMPRESSED to support compressed debug info - a lot of cleanups of modpost - dump vmlinux symbols out into vmlinux.symvers, and reuse it in the second pass of modpost - do not run the second pass of modpost if nothing in modules is updated - install modules.builtin(.modinfo) by 'make install' as well as by 'make modules_install' because it is useful even when CONFIG_MODULES=n - add new command line variables, GZIP, BZIP2, LZOP, LZMA, LZ4, and XZ to allow users to use alternatives such as pigz, pbzip2, etc. * tag 'kbuild-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (96 commits) kbuild: add variables for compression tools Makefile: install modules.builtin even if CONFIG_MODULES=n mksysmap: Fix the mismatch of '.L' symbols in System.map kbuild: doc: rename LDFLAGS to KBUILD_LDFLAGS modpost: change elf_info->size to size_t modpost: remove is_vmlinux() helper modpost: strip .o from modname before calling new_module() modpost: set have_vmlinux in new_module() modpost: remove mod->skip struct member modpost: add mod->is_vmlinux struct member modpost: remove is_vmlinux() call in check_for_{gpl_usage,unused}() modpost: remove mod->is_dot_o struct member modpost: move -d option in scripts/Makefile.modpost modpost: remove -s option modpost: remove get_next_text() and make {grab,release_}file static modpost: use read_text_file() and get_line() for reading text files modpost: avoid false-positive file open error modpost: fix potential mmap'ed file overrun in get_src_version() modpost: add read_text_file() and get_line() helpers modpost: do not call get_modinfo() for vmlinux(.o) ...
2020-06-06modpost: change elf_info->size to size_tMasahiro Yamada
Align with the mmap / munmap APIs. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-06modpost: remove is_vmlinux() helperMasahiro Yamada
Now that is_vmlinux() is called only in new_module(), we can inline the function call. modname is the basename with '.o' is stripped. No need to compare it with 'vmlinux.o'. vmlinux is always located at the current working directory. No need to strip the directory path. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>