aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2023-09-19kconfig: fix possible buffer overflowKonstantin Meskhidze
[ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ] Buffer 'new_argv' is accessed without bound check after accessing with bound check via 'new_argc' index. Fixes: e298f3b49def ("kconfig: add built-in function support") Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com> Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19kbuild: rpm-pkg: define _arch conditionallyMasahiro Yamada
[ Upstream commit 233046a2afd12a4f699305b92ee634eebf1e4f31 ] Commit 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") does not work as intended; _arch is always defined as $UTS_MACHINE. The intention was to define _arch to $UTS_MACHINE only when it is not defined. Fixes: 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13kbuild: rust_is_available: fix confusion when a version appears in the pathMiguel Ojeda
[ Upstream commit 9eb7e20e0c5cd069457845f965b3e8a7d736ecb7 ] `bindgen`'s output for `libclang`'s version check contains paths, which in turn may contain strings that look like version numbers [1][2]: .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0 [-W#pragma-messages], err: false which the script will pick up as the version instead of the latter. It is also the case that versions may appear after the actual version (e.g. distribution's version text), which was the reason behind `head` [3]: .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false Thus instead ask for a match after the `clang version` string. Reported-by: Jordan Isaacs <mail@jdisaacs.com> Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1] Reported-by: "Ethan D. Twardy" <ethan.twardy@gmail.com> Closes: https://lore.kernel.org/rust-for-linux/20230528131802.6390-2-ethan.twardy@gmail.com/ [2] Reported-by: Tiago Lam <tiagolam@gmail.com> Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3] Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Ethan Twardy <ethan.twardy@gmail.com> Tested-by: Ethan Twardy <ethan.twardy@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230616001631.463536-8-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13kbuild: rust_is_available: add check for `bindgen` invocationMiguel Ojeda
[ Upstream commit 52cae7f28ed6c3992489f16bb355f5b623f0912e ] `scripts/rust_is_available.sh` calls `bindgen` with a special header in order to check whether the `libclang` version in use is suitable. However, the invocation itself may fail if, for instance, `bindgen` cannot locate `libclang`. This is fine for Kconfig (since the script will still fail and therefore disable Rust as it should), but it is pretty confusing for users of the `rustavailable` target given the error will be unrelated: ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 * + 100 * + " make: *** [Makefile:1816: rustavailable] Error 2 Instead, run the `bindgen` invocation independently in a previous step, saving its output and return code. If it fails, then show the user a proper error message. Otherwise, continue as usual with the saved output. Since the previous patch we show a reference to the docs, and the docs now explain how `bindgen` looks for `libclang`, thus the error message can leverage the documentation, avoiding duplication here (and making users aware of the setup guide in the documentation). Reported-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/ Reported-by: François Valenduc <francoisvalenduc@gmail.com> Closes: https://github.com/Rust-for-Linux/linux/issues/934 Reported-by: Alexandru Radovici <msg4alex@gmail.com> Closes: https://github.com/Rust-for-Linux/linux/pull/921 Reported-by: Matthew Leach <dev@mattleach.net> Closes: https://lore.kernel.org/rust-for-linux/20230507084116.1099067-1-dev@mattleach.net/ Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230616001631.463536-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13kbuild: rust_is_available: fix version check when CC has multiple argumentsRussell Currey
[ Upstream commit dee3a6b819c96fc8b1907577f585fd66f5c0fefe ] rust_is_available.sh uses cc-version.sh to identify which C compiler is in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to be able to handle multiple arguments in one variable, i.e. "ccache clang". Its invocation in rust_is_available.sh quotes "$CC", which makes $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang. cc-version.sh could also be changed to handle having "ccache clang" as one argument, but it only has the one consumer upstream, making it simpler to fix the caller here. Signed-off-by: Russell Currey <ruscur@russell.cc> Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Link: https://github.com/Rust-for-Linux/linux/pull/873 [ Reworded title prefix and reflow line to 75 columns. ] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230616001631.463536-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13kbuild: rust_is_available: remove -v optionMasahiro Yamada
[ Upstream commit d824d2f98565e7c4cb1b862c230198fbe1a968be ] The -v option is passed when this script is invoked from Makefile, but not when invoked from Kconfig. As you can see in scripts/Kconfig.include, the 'success' macro suppresses stdout and stderr anyway, so this script does not need to be quiet. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230109061436.3146442-1-masahiroy@kernel.org [ Reworded prefix to match the others in the patch series. ] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230616001631.463536-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Stable-dep-of: dee3a6b819c9 ("kbuild: rust_is_available: fix version check when CC has multiple arguments") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-16gcc-plugins: Reorganize gimple includes for GCC 13Kees Cook
commit e6a71160cc145e18ab45195abf89884112e02dfb upstream. The gimple-iterator.h header must be included before gimple-fold.h starting with GCC 13. Reorganize gimple headers to work for all GCC versions. Reported-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/all/20230113173033.4380-1-palmer@rivosinc.com/ Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27scripts/kallsyms: update the usage in the comment blockMasahiro Yamada
commit 79549da691edd4874c19d99c578a134471817c47 upstream. Commit 010a0aad39fc ("kallsyms: Correctly sequence symbols when CONFIG_LTO_CLANG=y") added --lto-clang, and updated the usage() function, but not the comment. Update it in the same way. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27scripts/kallsyms.c Make the comment up-to-date with current implementationYuma Ueda
commit adc40221bf676f3e722d135889a7b913b4162dc2 upstream. The comment in scripts/kallsyms.c describing the usage of scripts/kallsyms does not reflect the latest implementation. Fix the comment to be equivalent to what the usage() function prints. Signed-off-by: Yuma Ueda <cyan@0x00a1e9.dev> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20221118133631.4554-1-cyan@0x00a1e9.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27kallsyms: add kallsyms_seqs_of_names to list of special symbolsArnd Bergmann
commit ced0f245ed951e2b8bd68f79c15238d7dd253662 upstream. My randconfig build setup ran into another kallsyms warning: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround After adding some debugging code to kallsyms.c, I saw that the recently added kallsyms_seqs_of_names symbol can sometimes cause the second stage table to be slightly longer than the first stage, which makes the build inconsistent. Add it to the exception table that contains all other kallsyms-generated symbols. Fixes: 60443c88f3a8 ("kallsyms: Improve the performance of kallsyms_lookup_name()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27kallsyms: strip LTO-only suffixes from promoted global functionsYonghong Song
[ Upstream commit 8cc32a9bbf2934d90762d9de0187adcb5ad46a11 ] Commit 6eb4bd92c1ce ("kallsyms: strip LTO suffixes from static functions") stripped all function/variable suffixes started with '.' regardless of whether those suffixes are generated at LTO mode or not. In fact, as far as I know, in LTO mode, when a static function/variable is promoted to the global scope, '.llvm.<...>' suffix is added. The existing mechanism breaks live patch for a LTO kernel even if no <symbol>.llvm.<...> symbols are involved. For example, for the following kernel symbols: $ grep bpf_verifier_vlog /proc/kallsyms ffffffff81549f60 t bpf_verifier_vlog ffffffff8268b430 d bpf_verifier_vlog._entry ffffffff8282a958 d bpf_verifier_vlog._entry_ptr ffffffff82e12a1f d bpf_verifier_vlog.__already_done 'bpf_verifier_vlog' is a static function. '_entry', '_entry_ptr' and '__already_done' are static variables used inside 'bpf_verifier_vlog', so llvm promotes them to file-level static with prefix 'bpf_verifier_vlog.'. Note that the func-level to file-level static function promotion also happens without LTO. Given a symbol name 'bpf_verifier_vlog', with LTO kernel, current mechanism will return 4 symbols to live patch subsystem which current live patching subsystem cannot handle it. With non-LTO kernel, only one symbol is returned. In [1], we have a lengthy discussion, the suggestion is to separate two cases: (1). new symbols with suffix which are generated regardless of whether LTO is enabled or not, and (2). new symbols with suffix generated only when LTO is enabled. The cleanup_symbol_name() should only remove suffixes for case (2). Case (1) should not be changed so it can work uniformly with or without LTO. This patch removed LTO-only suffix '.llvm.<...>' so live patching and tracing should work the same way for non-LTO kernel. The cleanup_symbol_name() in scripts/kallsyms.c is also changed to have the same filtering pattern so both kernel and kallsyms tool have the same expectation on the order of symbols. [1] https://lore.kernel.org/live-patching/20230615170048.2382735-1-song@kernel.org/T/#u Fixes: 6eb4bd92c1ce ("kallsyms: strip LTO suffixes from static functions") Reported-by: Song Liu <song@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20230628181926.4102448-1-yhs@fb.com Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27kallsyms: Correctly sequence symbols when CONFIG_LTO_CLANG=yZhen Lei
[ Upstream commit 010a0aad39fccceba4a07d30d163158a39c704f3 ] LLVM appends various suffixes for local functions and variables, suffixes observed: - foo.llvm.[0-9a-f]+ - foo.[0-9a-f]+ Therefore, when CONFIG_LTO_CLANG=y, kallsyms_lookup_name() needs to truncate the suffix of the symbol name before comparing the local function or variable name. Old implementation code: - if (strcmp(namebuf, name) == 0) - return kallsyms_sym_address(i); - if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0) - return kallsyms_sym_address(i); The preceding process is traversed by address from low to high. That is, for those with the same name after the suffix is removed, the one with the smallest address is returned first. Therefore, when sorting in the tool, if the raw names are the same, they should be sorted by address in ascending order. ASCII[.] = 2e ASCII[0-9] = 30,39 ASCII[A-Z] = 41,5a ASCII[_] = 5f ASCII[a-z] = 61,7a According to the preceding ASCII code values, the following sorting result is strictly followed. --------------------------------- | main-key | sub-key | |---------------------------------| | | addr_lowest | | <name> | ... | | <name>.<suffix> | ... | | | addr_highest | |---------------------------------| | <name>?<others> | | //? is [_A-Za-z0-9] --------------------------------- Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Stable-dep-of: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27kallsyms: Improve the performance of kallsyms_lookup_name()Zhen Lei
[ Upstream commit 60443c88f3a89fd303a9e8c0e84895910675c316 ] Currently, to search for a symbol, we need to expand the symbols in 'kallsyms_names' one by one, and then use the expanded string for comparison. It's O(n). If we sort names in ascending order like addresses, we can also use binary search. It's O(log(n)). In order not to change the implementation of "/proc/kallsyms", the table kallsyms_names[] is still stored in a one-to-one correspondence with the address in ascending order. Add array kallsyms_seqs_of_names[], it's indexed by the sequence number of the sorted names, and the corresponding content is the sequence number of the sorted addresses. For example: Assume that the index of NameX in array kallsyms_seqs_of_names[] is 'i', the content of kallsyms_seqs_of_names[i] is 'k', then the corresponding address of NameX is kallsyms_addresses[k]. The offset in kallsyms_names[] is get_symbol_offset(k). Note that the memory usage will increase by (4 * kallsyms_num_syms) bytes, the next two patches will reduce (1 * kallsyms_num_syms) bytes and properly handle the case CONFIG_LTO_CLANG=y. Performance test results: (x86) Before: min=234, max=10364402, avg=5206926 min=267, max=11168517, avg=5207587 After: min=1016, max=90894, avg=7272 min=1014, max=93470, avg=7293 The average lookup performance of kallsyms_lookup_name() improved 715x. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Stable-dep-of: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19kbuild: Disable GCOV for *.mod.oSami Tolvanen
[ Upstream commit 25a21fbb934a0d989e1858f83c2ddf4cfb2ebe30 ] With GCOV_PROFILE_ALL, Clang injects __llvm_gcov_* functions to each object file, including the *.mod.o. As we filter out CC_FLAGS_CFI for *.mod.o, the compiler won't generate type hashes for the injected functions, and therefore indirectly calling them during module loading trips indirect call checking. Enabling CFI for *.mod.o isn't sufficient to fix this issue after commit 0c3e806ec0f9 ("x86/cfi: Add boot time hash randomization"), as *.mod.o aren't processed by objtool, which means any hashes emitted there won't be randomized. Therefore, in addition to disabling CFI for *.mod.o, also disable GCOV, as the object files don't otherwise contain any executable code. Fixes: cf68fffb66d6 ("add support for Clang CFI") Reported-by: Joe Fradley <joefradley@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19modpost: fix off by one in is_executable_section()Dan Carpenter
[ Upstream commit 3a3f1e573a105328a2cca45a7cfbebabbf5e3192 ] The > comparison should be >= to prevent an out of bounds array access. Fixes: 52dc0595d540 ("modpost: handle relocations mismatch in __ex_table.") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19modpost: fix section mismatch message for R_ARM_{PC24,CALL,JUMP24}Masahiro Yamada
[ Upstream commit 56a24b8ce6a7f9c4a21b2276a8644f6f3d8fc14d ] addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a wrong way. Here, test code. [test code for R_ARM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with ARM multi_v7_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I imported (with adjustment) sign_extend32() from include/linux/bitops.h. The '+8' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Fixes: 6e2e340b59d2 ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19modpost: fix section mismatch message for R_ARM_ABS32Masahiro Yamada
[ Upstream commit b7c63520f6703a25eebb4f8138fed764fcae1c6f ] addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19modpost: remove broken calculation of exception_table_entry sizeMasahiro Yamada
[ Upstream commit d0acc76a49aa917c1a455d11d32d34a01e8b2835 ] find_extable_entry_size() is completely broken. It has awesome comments about how to calculate sizeof(struct exception_table_entry). It was based on these assumptions: - struct exception_table_entry has two fields - both of the fields have the same size Then, we came up with this equation: (offset of the second field) * 2 == (size of struct) It was true for all architectures when commit 52dc0595d540 ("modpost: handle relocations mismatch in __ex_table.") was applied. Our mathematics broke when commit 548acf19234d ("x86/mm: Expand the exception table logic to allow new handling options") introduced the third field. Now, the definition of exception_table_entry is highly arch-dependent. For x86, sizeof(struct exception_table_entry) is apparently 12, but find_extable_entry_size() sets extable_entry_size to 8. I could fix it, but I do not see much value in this code. extable_entry_size is used just for selecting a slightly different error message. If the first field ("insn") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW it is not possible for the kernel to fault at that address. Something is seriously wrong and should be fixed. If the second field ("fixup") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW the kernel will fault if it ever tries to jump to it. Something is seriously wrong and should be fixed. Merge the two error messages rather than adding even more complexity. Change fatal() to error() to make it continue running and catch more possible errors. Fixes: 548acf19234d ("x86/mm: Expand the exception table logic to allow new handling options") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-05scripts/tags.sh: Resolve gtags empty index generationAhmed S. Darwish
commit e1b37563caffc410bb4b55f153ccb14dede66815 upstream. gtags considers any file outside of its current working directory "outside the source tree" and refuses to index it. For O= kernel builds, or when "make" is invoked from a directory other then the kernel source tree, gtags ignores the entire kernel source and generates an empty index. Force-set gtags current working directory to the kernel source tree. Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in a subdir of the source tree"), if the kernel build is done in a sub-directory of the kernel source tree, the kernel Makefile will set the kernel's $srctree to ".." for shorter compile-time and run-time warnings. Consequently, the list of files to be indexed will be in the "../*" form, rendering all such paths invalid once gtags switches to the kernel source tree as its current working directory. If gtags indexing is requested and the build directory is not the kernel source tree, index all files in absolute-path form. Note, indexing in absolute-path form will not affect the generated index, as paths in gtags indices are always relative to the gtags "root directory" anyway (as evidenced by "gtags --dump"). Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-28scripts: fix the gfp flags header path in gfp-translatePrathu Baronia
commit 2049a7d0cbc6ac8e370e836ed68597be04a7dc49 upstream. Since gfp flags have been shifted to gfp_types.h so update the path in the gfp-translate script. Link: https://lkml.kernel.org/r/20230608154450.21758-1-prathubaronia2011@gmail.com Fixes: cb5a065b4ea9c ("headers/deps: mm: Split <linux/gfp_types.h> out of <linux/gfp.h>") Signed-off-by: Prathu Baronia <prathubaronia2011@gmail.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Ingo Molnar <mingo@kernel.org> Cc: Yury Norov <yury.norov@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21kbuild: Update assembler calls to use proper flags and language targetNick Desaulniers
commit d5c8d6e0fa61401a729e9eb6a9c7077b2d3aebb0 upstream. as-instr uses KBUILD_AFLAGS, but as-option uses KBUILD_CFLAGS. This can cause as-option to fail unexpectedly when CONFIG_WERROR is set, because clang will emit -Werror,-Wunused-command-line-argument for various -m and -f flags in KBUILD_CFLAGS for assembler sources. Callers of as-option and as-instr should be adding flags to KBUILD_AFLAGS / aflags-y, not KBUILD_CFLAGS / cflags-y. Use KBUILD_AFLAGS in all macros to clear up the initial problem. Unfortunately, -Wunused-command-line-argument can still be triggered with clang by the presence of warning flags or macro definitions because '-x assembler' is used, instead of '-x assembler-with-cpp', which will consume these flags. Switch to '-x assembler-with-cpp' in places where '-x assembler' is used, as the compiler is always used as the driver for out of line assembler sources in the kernel. Finally, add -Werror to these macros so that they behave consistently whether or not CONFIG_WERROR is set. [nathan: Reworded and expanded on problems in commit message Use '-x assembler-with-cpp' in a couple more places] Link: https://github.com/ClangBuiltLinux/linux/issues/1699 Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-24recordmcount: Fix memory leaks in the uwrite functionHao Zeng
[ Upstream commit fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9 ] Common realloc mistake: 'file_append' nulled but not freed upon failure Link: https://lkml.kernel.org/r/20230426010527.703093-1-zenghao@kylinos.cn Signed-off-by: Hao Zeng <zenghao@kylinos.cn> Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11scripts/gdb: fix lx-timerlist for Python3Peng Liu
commit 7362042f3556528e9e9b1eb5ce8d7a3a6331476b upstream. Below incompatibilities between Python2 and Python3 made lx-timerlist fail to run under Python3. o xrange() is replaced by range() in Python3 o bytes and str are different types in Python3 o the return value of Inferior.read_memory() is memoryview object in Python3 akpm: cc stable so that older kernels are properly debuggable under newer Python. Link: https://lkml.kernel.org/r/TYCP286MB2146EE1180A4D5176CBA8AB2C6819@TYCP286MB2146.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Peng Liu <liupeng17@lenovo.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-11scripts/gdb: raise error with reduced debugging informationFlorian Fainelli
[ Upstream commit 8af055ae25bff48f57227f5e3d48a4306f3dd1c4 ] If CONFIG_DEBUG_INFO_REDUCED is enabled in the kernel configuration, we will typically not be able to load vmlinux-gdb.py and will fail with: Traceback (most recent call last): File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/vmlinux-gdb.py", line 25, in <module> import linux.utils File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/scripts/gdb/linux/utils.py", line 131, in <module> atomic_long_counter_offset = atomic_long_type.get_type()['counter'].bitpos KeyError: 'counter' Rather be left wondering what is happening only to find out that reduced debug information is the cause, raise an eror. This was not typically a problem until e3c8d33e0d62 ("scripts/gdb: fix 'lx-dmesg' on 32 bits arch") but it has since then. Link: https://lkml.kernel.org/r/20230406215252.1580538-1-f.fainelli@gmail.com Fixes: e3c8d33e0d62 ("scripts/gdb: fix 'lx-dmesg' on 32 bits arch") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Cc: Antonio Borneo <antonio.borneo@foss.st.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11scripts/gdb: bail early if there are no generic PDFlorian Fainelli
[ Upstream commit f19c3c2959e465209ade1a7a699e6cbf4359ce78 ] Avoid generating an exception if there are no generic power domain(s) registered: (gdb) lx-genpd-summary domain status children /device runtime status ---------------------------------------------------------------------- Python Exception <class 'gdb.error'>: No symbol "gpd_list" in current context. Error occurred in Python: No symbol "gpd_list" in current context. (gdb) quit [f.fainelli@gmail.com: correctly invoke gdb_eval_or_none] Link: https://lkml.kernel.org/r/20230327185746.3856407-1-f.fainelli@gmail.com Link: https://lkml.kernel.org/r/20230323231659.3319941-1-f.fainelli@gmail.com Fixes: 8207d4a88e1e ("scripts/gdb: add lx-genpd-summary command") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11scripts/gdb: bail early if there are no clocksFlorian Fainelli
[ Upstream commit 1d7adbc74c009057ed9dc3112f388e91a9c79acc ] Avoid generating an exception if there are no clocks registered: (gdb) lx-clk-summary enable prepare protect clock count count count rate ------------------------------------------------------------------------ Python Exception <class 'gdb.error'>: No symbol "clk_root_list" in current context. Error occurred in Python: No symbol "clk_root_list" in current context. Link: https://lkml.kernel.org/r/20230323225246.3302977-1-f.fainelli@gmail.com Fixes: d1e9710b63d8 ("scripts/gdb: initial clk support: lx-clk-summary") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26ASN.1: Fix check for strdup() successEkaterina Orlova
commit 5a43001c01691dcbd396541e6faa2c0077378f48 upstream. It seems there is a misprint in the check of strdup() return code that can lead to NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4520c6a49af8 ("X.509: Add simple ASN.1 grammar compiler") Signed-off-by: Ekaterina Orlova <vorobushek.ok@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: keyrings@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Link: https://lore.kernel.org/r/20230315172130.140-1-vorobushek.ok@gmail.com/ Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-06modpost: Fix processing of CRCs on 32-bit build machinesBen Hutchings
commit fb27e70f6e408dee5d22b083e7a38a59e6118253 upstream. modpost now reads CRCs from .*.cmd files, parsing them using strtol(). This is inconsistent with its parsing of Module.symvers and with their definition as *unsigned* 32-bit values. strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a 32-bit system this changes all CRCs >= 0x80000000 to be 0x7fffffff. Change extract_crcs_for_object() to use strtoul() instead. Cc: stable@vger.kernel.org Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22kconfig: Update config changed flag before calling callbackJurica Vukadin
[ Upstream commit ee06a3ef7e3cddb62b90ac40aa661d3c12f7cabc ] Prior to commit 5ee546594025 ("kconfig: change sym_change_count to a boolean flag"), the conf_updated flag was set to the new value *before* calling the callback. xconfig's save action depends on this behaviour, because xconfig calls conf_get_changed() directly from the callback and now sees the old value, thus never enabling the save button or the shortcut. Restore the previous behaviour. Fixes: 5ee546594025 ("kconfig: change sym_change_count to a boolean flag") Signed-off-by: Jurica Vukadin <jura@vukad.in> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17scripts: handle BrokenPipeError for python scriptsMasahiro Yamada
[ Upstream commit 87c7ee67deb7fce9951a5f9d80641138694aad17 ] In the follow-up of commit fb3041d61f68 ("kbuild: fix SIGPIPE error message for AR=gcc-ar and AR=llvm-ar"), Kees Cook pointed out that tools should _not_ catch their own SIGPIPEs [1] [2]. Based on his feedback, LLVM was fixed [3]. However, Python's default behavior is to show noisy bracktrace when SIGPIPE is sent. So, scripts written in Python are basically in the same situation as the buggy llvm tools. Example: $ make -s allnoconfig $ make -s allmodconfig $ scripts/diffconfig .config.old .config | head -n1 -ALIX n Traceback (most recent call last): File "/home/masahiro/linux/scripts/diffconfig", line 132, in <module> main() File "/home/masahiro/linux/scripts/diffconfig", line 130, in main print_config("+", config, None, b[config]) File "/home/masahiro/linux/scripts/diffconfig", line 64, in print_config print("+%s %s" % (config, new_value)) BrokenPipeError: [Errno 32] Broken pipe Python documentation [4] notes how to make scripts die immediately and silently: """ Piping output of your program to tools like head(1) will cause a SIGPIPE signal to be sent to your process when the receiver of its standard output closes early. This results in an exception like BrokenPipeError: [Errno 32] Broken pipe. To handle this case, wrap your entry point to catch this exception as follows: import os import sys def main(): try: # simulate large output (your code replaces this loop) for x in range(10000): print("y") # flush output here to force SIGPIPE to be triggered # while inside this try block. sys.stdout.flush() except BrokenPipeError: # Python flushes standard streams on exit; redirect remaining output # to devnull to avoid another BrokenPipeError at shutdown devnull = os.open(os.devnull, os.O_WRONLY) os.dup2(devnull, sys.stdout.fileno()) sys.exit(1) # Python exits with error code 1 on EPIPE if __name__ == '__main__': main() Do not set SIGPIPE’s disposition to SIG_DFL in order to avoid BrokenPipeError. Doing that would cause your program to exit unexpectedly whenever any socket connection is interrupted while your program is still writing to it. """ Currently, tools/perf/scripts/python/intel-pt-events.py seems to be the only script that fixes the issue that way. tools/perf/scripts/python/compaction-times.py uses another approach signal.signal(signal.SIGPIPE, signal.SIG_DFL) but the Python documentation clearly says "Don't do it". I cannot fix all Python scripts since there are so many. I fixed some in the scripts/ directory. [1]: https://lore.kernel.org/all/202211161056.1B9611A@keescook/ [2]: https://github.com/llvm/llvm-project/issues/59037 [3]: https://github.com/llvm/llvm-project/commit/4787efa38066adb51e2c049499d25b3610c0877b [4]: https://docs.python.org/3/library/signal.html#note-on-sigpipe Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10gcc-plugins: drop -std=gnu++11 to fix GCC 13 buildSam James
[ Upstream commit 5a6b64adc18d9adfb497a529ff004d59b6df151f ] The latest GCC 13 snapshot (13.0.1 20230129) gives the following: ``` cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so :./scripts/gcc-plugins/randomize_layout_plugin.so: undefined symbol: tree_code_type ``` This ends up being because of https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=b0241ce6e37031 upstream in GCC which changes the visibility of some types used by the kernel's plugin infrastructure like tree_code_type. After discussion with the GCC folks, we found that the kernel needs to be building plugins with the same flags used to build GCC - and GCC defaults to gnu++17 right now. The minimum GCC version needed to build the kernel is GCC 5.1 and GCC 5.1 already defaults to gnu++14 anyway, so just drop the flag, as all GCCs that could be used to build GCC already default to an acceptable version which was >= the version we forced via flags until now. Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230201230009.2252783-1-sam@gentoo.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10builddeb: clean generated package contentBastian Germann
[ Upstream commit c9f9cf2560e40b62015c6c4a04be60f55ce5240e ] For each binary Debian package, a directory with the package name is created in the debian directory. Correct the generated file matches in the package's clean target, which were renamed without adjusting the target. Fixes: 1694e94e4f46 ("builddeb: match temporary directory name to the package name") Signed-off-by: Bastian Germann <bage@linutronix.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-03scripts/tags.sh: fix incompatibility with PCRE2Carlos Llamas
commit 6ec363fc6142226b9ab5a6528f65333d729d2b6b upstream. Starting with release 10.38 PCRE2 drops default support for using \K in lookaround patterns as described in [1]. Unfortunately, scripts/tags.sh relies on such functionality to collect all_compiled_soures() leading to the following error: $ make COMPILED_SOURCE=1 tags GEN tags grep: \K is not allowed in lookarounds (but see PCRE2_EXTRA_ALLOW_LOOKAROUND_BSK) The usage of \K for this pattern was introduced in commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which speeds up the generation of tags significantly. In order to fix this issue without compromising the performance we can switch over to an equivalent sed expression. The same matching pattern is preserved here except \K is replaced with a backreference \1. [1] https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC11 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Jialu Xu <xujialu@vimux.org> Cc: Vipin Sharma <vipinsh@google.com> Cc: stable@vger.kernel.org Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20230215183850.3353198-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-25arm64: remove special treatment for the link order of head.oMasahiro Yamada
commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream. In the previous discussion (see the Link tag), Ard pointed out that arm/arm64/kernel/head.o does not need any special treatment - the only piece that must appear right at the start of the binary image is the image header which is emitted into .head.text. The linker script does the right thing to do. The build system does not need to manipulate the link order of head.o. Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=EuA@mail.gmail.com/ Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Link: https://lore.kernel.org/r/20221012233500.156764-1-masahiroy@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-25riscv: remove special treatment for the link order of head.oJisheng Zhang
commit 2348e6bf44213c5f447ff698e43c089185241ed7 upstream. arch/riscv/kernel/head.o does not need any special treatment - the only requirement is the ".head.text" section must be placed before the normal ".text" section. The linker script does the right thing to do. The build system does not need to manipulate the link order of head.o. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20221018141200.1040-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-09kbuild: modinst: Fix build error when CONFIG_MODULE_SIG_KEY is a PKCS#11 URIJan Luebbe
[ Upstream commit 22e46f6480e83bcf49b6d5e6b66c81872c97a902 ] When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*), signing of modules fails: scripts/sign-file sha256 /.../linux/pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509 /.../kernel/crypto/tcrypt.ko Usage: scripts/sign-file [-dp] <hash algo> <key> <x509> <module> [<dest>] scripts/sign-file -s <raw sig> <hash algo> <x509> <module> [<dest>] First, we need to avoid adding the $(srctree)/ prefix to the URL. Second, since the kconfig string values no longer include quotes, we need to add them again when passing a PKCS#11 URI to sign-file. This avoids splitting by the shell if the URI contains semicolons. Fixes: 4db9c2e3d055 ("kbuild: stop using config_filename in scripts/Makefile.modsign") Fixes: 129ab0d2d9f3 ("kbuild: do not quote string values in include/config/auto.conf") Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01Fix up more non-executable files marked executableLinus Torvalds
[ Upstream commit c96618275234ad03d44eafe9f8844305bb44fda4 ] Joe found another DT file that shouldn't be executable, and that frustrated me enough that I went hunting with this script: git ls-files -s | grep '^100755' | cut -f2 | xargs grep -L '^#!' and that found another file that shouldn't have been marked executable either, despite being in the scripts directory. Maybe these two are the last ones at least for now. But I'm sure we'll be back in a few years, fixing things up again. Fixes: 8c6789f4e2d4 ("ASoC: dt-bindings: Add Everest ES8326 audio CODEC") Fixes: 4d8e5cd233db ("locking/atomics: Fix scripts/atomic/ script permissions") Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01ftrace/scripts: Update the instructions for ftrace-bisect.shSteven Rostedt (Google)
commit 7ae4ba7195b1bac04a4210a499da9d8c63b0ba9c upstream. The instructions for the ftrace-bisect.sh script, which is used to find what function is being traced that is causing a kernel crash, and possibly a triple fault reboot, uses the old method. In 5.1, a new feature was added that let the user write in the index into available_filter_functions that maps to the function a user wants to set in set_ftrace_filter (or set_ftrace_notrace). This takes O(1) to set, as suppose to writing a function name, which takes O(n) (where n is the number of functions in available_filter_functions). The ftrace-bisect.sh requires setting half of the functions in available_filter_functions, which is O(n^2) using the name method to enable and can take several minutes to complete. The number method is O(n) which takes less than a second to complete. Using the number method for any kernel 5.1 and after is the proper way to do the bisect. Update the usage to reflect the new change, as well as using the /sys/kernel/tracing path instead of the obsolete debugfs path. Link: https://lkml.kernel.org/r/20230123112252.022003dd@gandalf.local.home Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Fixes: f79b3f338564e ("ftrace: Allow enabling of filters via index of available_filter_functions") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-27Merge tag 'objtool_urgent_for_v6.1_rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fix from Borislav Petkov: - Handle different output of readelf on different distros running ppc64le which confuses faddr2line's function offsets conversion * tag 'objtool_urgent_for_v6.1_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: scripts/faddr2line: Fix regression in name resolution on ppc64le
2022-11-24scripts: add rust in scripts/Makefile.packageParan Lee
Add rust argument at TAR_CONTENT in scripts/Makefile.package script with alphabetical order. Signed-off-by: Paran Lee <p4ranlee@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-11-17kbuild: Restore .version auto-increment behaviour for Debian packagesMarc Zyngier
Since 2df8220cc511 ("kbuild: build init/built-in.a just once"), generating Debian packages using 'make bindeb-pkg' results in packages that are stuck to the same .version, leading to unexpected behaviours (multiple packages with the same version). That's because the mkdebian script samples the build version before building the kernel, and forces the use of that version number for the actual build. Restore the previous behaviour by calling init/build-version instead of reading the .version file. This is likely to result in too many .version bumps, but this is what was happening before (although the bump was affecting builds made after the current one). Fixes: 2df8220cc511 ("kbuild: build init/built-in.a just once") Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-11-16scripts/faddr2line: Fix regression in name resolution on ppc64leSrikar Dronamraju
Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures") can cause faddr2line to fail on ppc64le on some distributions, while it works fine on other distributions. The failure can be attributed to differences in the readelf output. $ ./scripts/faddr2line vmlinux find_busiest_group+0x00 no match for find_busiest_group+0x00 On ppc64le, readelf adds the localentry tag before the symbol name on some distributions, and adds the localentry tag after the symbol name on other distributions. This problem has been discussed previously: https://lore.kernel.org/bpf/20191211160133.GB4580@calabresa/ This problem can be overcome by filtering out the localentry tags in the readelf output. Similar fixes are already present in the kernel by way of the following commits: 1fd6cee127e2 ("libbpf: Fix VERSIONED_SYM_COUNT number parsing") aa915931ac3e ("libbpf: Fix readelf output parsing for Fedora") [jpoimboe: rework commit log] Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures") Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Link: https://lore.kernel.org/r/20220927075211.897152-1-srikar@linux.vnet.ibm.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org>
2022-11-11Merge tag 's390-6.1-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Alexander Gordeev: - fix memcpy warning about field-spanning write in zcrypt driver - minor updates to defconfigs - remove CONFIG_DEBUG_INFO_BTF from all defconfigs and add btf.config addon config file. It significantly decreases compile time and allows quickly enabling that option into the current kernel config - add kasan.config addon config file which allows to easily enable KASAN into the current kernel config - binutils commit 906f69cf65da ("IBM zSystems: Issue error for *DBL relocs on misaligned symbols") caused several link errors. Always build relocatable kernel to avoid this problem - raise the minimum clang version to 15.0.0 to avoid silent generation of a corrupted code * tag 's390-6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390 s390: always build relocatable kernel s390/configs: add kasan.config addon config file s390/configs: move CONFIG_DEBUG_INFO_BTF into btf.config addon config s390: update defconfigs s390/zcrypt: fix warning about field-spanning write
2022-11-09scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390Heiko Carstens
Before version 15.0.0 llvm's integrated assembler may silently generate corrupted code on s390. See e.g. commit e9953b729b78 ("s390/boot: workaround llvm IAS bug") for further details. While there have been workarounds applied for all known existing locations, there is nothing that prevents that new code with problematic patterns will be added. Therefore raise the minimum clang version to 15.0.0. Note that llvm commit e547b04d5b2c ("[SystemZ] Bugfix for symbolic displacements."), which is included in 15.0.0, fixes the broken code generation. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20221031123456.3872220-1-hca@linux.ibm.com Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-11-02kconfig: fix segmentation fault in menuconfig searchMasahiro Yamada
Since commit d05377e184fc ("kconfig: Create links to main menu items in search"), menuconfig shows a jump key next to "Main menu" if the nearest visible parent is the rootmenu. If you press that jump key, menuconfig crashes with a segmentation fault. For example, do this: $ make ARCH=arm64 allnoconfig menuconfig Press '/' to search for the string "ACPI". Press '1' to choose "(1) Main menu". Then, menuconfig crashed with a segmentation fault. The following code in search_conf() conf(targets[i]->parent, targets[i]); results in NULL pointer dereference because targets[i] is the rootmenu, which does not have a parent. Commit d05377e184fc tried to fix the issue of top-level items not having a jump key, but adding the "Main menu" was not the right fix. The correct fix is to show the searched item itself. This fixes another weird behavior described in the comment block. Fixes: d05377e184fc ("kconfig: Create links to main menu items in search") Reported-by: Johannes Zink <j.zink@pengutronix.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Johannes Zink <j.zink@pengutronix.de>
2022-10-28kbuild: fix typo in modpostWill McVicker
Commit f73edc8951b2 ("kbuild: unify two modpost invocations") introduced a typo (moudle.symvers-if-present) which results in the kernel's Module.symvers to not be included as a prerequisite for $(KBUILD_EXTMOD)/Module.symvers. Fix the typo to restore the intended functionality. Fixes: f73edc8951b2 ("kbuild: unify two modpost invocations") Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-10-16Merge tag 'kbuild-fixes-v6.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y compile error for the combination of Clang >= 14 and GAS <= 2.35. - Drop vmlinux.bz2 from the rpm package as it just annoyingly increased the package size. - Fix modpost error under build environments using musl. - Make *.ll files keep value names for easier debugging - Fix single directory build - Prevent RISC-V from selecting the broken DWARF5 support when Clang and GAS are used together. * tag 'kbuild-fixes-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 kbuild: fix single directory build kbuild: add -fno-discard-value-names to cmd_cc_ll_c scripts/clang-tools: Convert clang-tidy args to list modpost: put modpost options before argument kbuild: Stop including vmlinux.bz2 in the rpm's Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5
2022-10-15kbuild: add -fno-discard-value-names to cmd_cc_ll_cNick Desaulniers
When debugging LLVM IR, it can be handy for clang to not discard value names used for local variables and parameters. Compare the generated IR. -fdiscard-value-names: define i32 @core_sys_select(i32 %0, ptr %1, ptr %2, ptr %3, ptr %4) { %6 = alloca i64 %7 = alloca %struct.poll_wqueues %8 = alloca [64 x i32] -fno-discard-value-names: define i32 @core_sys_select(i32 %n, ptr %inp, ptr %outp, ptr %exp, ptr %end_time) { %expire.i = alloca i64 %table.i = alloca %struct.poll_wqueues %stack_fds = alloca [64 x i32] The rule for generating human readable LLVM IR (.ll) is only useful as a debugging feature: $ make LLVM=1 fs/select.ll As Fangrui notes: A LLVM_ENABLE_ASSERTIONS=off build of Clang defaults to -fdiscard-value-names. A LLVM_ENABLE_ASSERTIONS=on build of Clang defaults to -fno-discard-value-names. Explicitly enable -fno-discard-value-names so that the IR always contains value names regardless of whether assertions were enabled or not. Assertions generally are not enabled in releases of clang packaged by distributions. Link: https://github.com/ClangBuiltLinux/linux/issues/1467 Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-10-14scripts/clang-tools: Convert clang-tidy args to listGuru Das Srinagesh
Convert list of clang-tidy arguments to a list for ease of adding to them and extending them as required. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-10-14modpost: put modpost options before argumentRichard Acayan
The musl implementation of getopt stops looking for options after the first non-option argument. Put the options before the non-option argument so environments using musl can still build the kernel and modules. Fixes: f73edc8951b2 ("kbuild: unify two modpost invocations") Link: https://git.musl-libc.org/cgit/musl/tree/src/misc/getopt.c?h=dc9285ad1dc19349c407072cc48ba70dab86de45#n44 Signed-off-by: Richard Acayan <mailingradian@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-28 22:52:11 +0000