kernel/linux.git/scripts, branch v5.15.155

gcc-plugins/stackleak: Avoid .head.text section

2024-04-13T11:01:47+00:00

commit e7d24c0aa8e678f41457d1304e2091cac6fd1a2e upstream. The .head.text section carries the startup code that runs with the MMU off or with a translation of memory that deviates from the ordinary one. So avoid instrumentation with the stackleak plugin, which already avoids .init.text and .noinstr.text entirely. Fixes: 48204aba801f1b51 ("x86/sme: Move early SME kernel encryption handling into .head.text") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202403221630.2692c998-oliver.sang@intel.com Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20240328064256.2358634-2-ardb+git@google.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

gcc-plugins/stackleak: Ignore .noinstr.text and .entry.text

2024-04-13T11:01:47+00:00

commit ae978009fc013e3166c9f523f8b17e41a3c0286e upstream. The .noinstr.text section functions may not have "current()" sanely available. Similarly true for .entry.text, though such a check is currently redundant. Add a check for both. In an x86_64 defconfig build, the following functions no longer receive stackleak instrumentation: __do_fast_syscall_32() do_int80_syscall_32() do_machine_check() do_syscall_64() exc_general_protection() fixup_bad_iret() Suggested-by: Peter Zijlstra Cc: Alexander Popov Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1

2024-04-10T14:18:41+00:00

[ Upstream commit 75b5ab134bb5f657ef7979a59106dce0657e8d87 ] Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional under -Wenum-conversion. A recent change in Clang strengthened these warnings and they appear frequently in common builds, primarily due to several instances in common headers but there are quite a few drivers that have individual instances as well. include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional] 955 | flags |= is_new_rate ? IWL_MAC_BEACON_CCK | ^ ~~~~~~~~~~~~~~~~~~ 956 | : IWL_MAC_BEACON_CCK_V1; | ~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional] 1120 | 0) > 10 ? | ^ 1121 | IWL_MAC_BEACON_FILS : | ~~~~~~~~~~~~~~~~~~~ 1122 | IWL_MAC_BEACON_FILS_V1; | ~~~~~~~~~~~~~~~~~~~~~~ Doing arithmetic between or returning two different types of enums could be a bug, so each of the instance of the warning needs to be evaluated. Unfortunately, as mentioned above, there are many instances of this warning in many different configurations, which can break the build when CONFIG_WERROR is enabled. To avoid introducing new instances of the warnings while cleaning up the disruption for the majority of users, disable these warnings for the default build while leaving them on for W=1 builds. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2002 Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e Acked-by: Yonghong Song Signed-off-by: Nathan Chancellor Acked-by: Arnd Bergmann Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix infinite loop when expanding a macro at the end of file

2024-03-26T22:21:34+00:00

[ Upstream commit af8bbce92044dc58e4cc039ab94ee5d470a621f5 ] A macro placed at the end of a file with no newline causes an infinite loop. [Test Kconfig] $(info,hello) \ No newline at end of file I realized that flex-provided input() returns 0 instead of EOF when it reaches the end of a file. Fixes: 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

gen_compile_commands: fix invalid escape sequence warning

2024-03-26T22:21:12+00:00

[ Upstream commit dae4a0171e25884787da32823b3081b4c2acebb2 ] With python 3.12, '\#' results in this warning SyntaxWarning: invalid escape sequence '\#' Signed-off-by: Andrew Ballance Reviewed-by: Justin Stitt Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

bpf, scripts: Correct GPL license name

2024-03-01T12:21:58+00:00

[ Upstream commit e37243b65d528a8a9f8b9a57a43885f8e8dfc15c ] The bpf_doc script refers to the GPL as the "GNU Privacy License". I strongly suspect that the author wanted to refer to the GNU General Public License, under which the Linux kernel is released, as, to the best of my knowledge, there is no license named "GNU Privacy License". This patch corrects the license name in the script accordingly. Fixes: 56a092c89505 ("bpf: add script and prepare bpf.h for new helpers documentation") Signed-off-by: Gianmarco Lusvardi Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240213230544.930018-3-glusvardi@posteo.net Signed-off-by: Sasha Levin

scripts/decode_stacktrace.sh: optionally use LLVM utilities

2024-02-23T07:55:13+00:00

[ Upstream commit efbd6398353315b7018e6943e41fee9ec35e875f ] GNU's addr2line can have problems parsing a vmlinux built with LLVM, particularly when LTO was used. In order to decode the traces correctly this patch adds the ability to switch to LLVM's utilities readelf and addr2line. The same approach is followed by Will in [1]. Before: $ scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (??:?) [17716.240654] esp6_input (ld-temp.o:?) [17716.240666] xfrm_input (ld-temp.o:?) [17716.240674] xfrm6_rcv (??:?) [...] After: $ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503) [17716.240654] esp6_input (net/ipv6/esp6.c:977) [17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659) [17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172) [...] Note that one could set CROSS_COMPILE=llvm- instead to hack around this issue. However, doing so can break the decodecode routine as it will force the selection of other LLVM utilities down the line e.g. llvm-as. [1] https://lore.kernel.org/all/20230914131225.13415-3-will@kernel.org/ Link: https://lkml.kernel.org/r/20230929034836.403735-1-cmllamas@google.com Signed-off-by: Carlos Llamas Reviewed-by: Nick Desaulniers Reviewed-by: Elliot Berman Tested-by: Justin Stitt Cc: Will Deacon Cc: John Stultz Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Tom Rix Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

scripts: decode_stacktrace: demangle Rust symbols

2024-02-23T07:55:13+00:00

[ Upstream commit 99115db4ecc87af73415939439ec604ea0531e6f ] Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`) provide Rust v0 mangling support. Reviewed-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Signed-off-by: Miguel Ojeda Stable-dep-of: efbd63983533 ("scripts/decode_stacktrace.sh: optionally use LLVM utilities") Signed-off-by: Sasha Levin

scripts/decode_stacktrace.sh: support old bash version

2024-02-23T07:55:13+00:00

[ Upstream commit 3af8acf6aff2a98731522b52927429760f0b8006 ] Old bash version don't support associative array variables. Avoid to use associative array variables to avoid error. Without this, old bash version will report error as fellowing [ 15.954042] Kernel panic - not syncing: sysrq triggered crash [ 15.955252] CPU: 1 PID: 167 Comm: sh Not tainted 5.18.0-rc1-00208-gb7d075db2fd5 #4 [ 15.956472] Hardware name: Hobot J5 Virtual development board (DT) [ 15.957856] Call trace: ./scripts/decode_stacktrace.sh: line 128: ,dump_backtrace: syntax error: operand expected (error token is ",dump_backtrace") Link: https://lkml.kernel.org/r/20220409180331.24047-1-schspa@gmail.com Signed-off-by: Schspa Shi Cc: Stephen Boyd Signed-off-by: Andrew Morton Stable-dep-of: efbd63983533 ("scripts/decode_stacktrace.sh: optionally use LLVM utilities") Signed-off-by: Sasha Levin

kbuild: Fix changing ELF file type for output of gen_btf for big endian

2024-02-23T07:55:05+00:00

commit e3a9ee963ad8ba677ca925149812c5932b49af69 upstream. Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF") changed the ELF type of .btf.vmlinux.bin.o to ET_REL via dd, which works fine for little endian platforms: 00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| -00000010 03 00 b7 00 01 00 00 00 00 00 00 80 00 80 ff ff |................| +00000010 01 00 b7 00 01 00 00 00 00 00 00 80 00 80 ff ff |................| However, for big endian platforms, it changes the wrong byte, resulting in an invalid ELF file type, which ld.lld rejects: 00000000 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 |.ELF............| -00000010 00 03 00 16 00 00 00 01 00 00 00 00 00 10 00 00 |................| +00000010 01 03 00 16 00 00 00 01 00 00 00 00 00 10 00 00 |................| Type: : 103 ld.lld: error: .btf.vmlinux.bin.o: unknown file type Fix this by updating the entire 16-bit e_type field rather than just a single byte, so that everything works correctly for all platforms and linkers. 00000000 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 |.ELF............| -00000010 00 03 00 16 00 00 00 01 00 00 00 00 00 10 00 00 |................| +00000010 00 01 00 16 00 00 00 01 00 00 00 00 00 10 00 00 |................| Type: REL (Relocatable file) While in the area, update the comment to mention that binutils 2.35+ matches LLD's behavior of rejecting an ET_EXEC input, which occurred after the comment was added. Cc: stable@vger.kernel.org Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF") Link: https://github.com/llvm/llvm-project/pull/75643 Suggested-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Reviewed-by: Fangrui Song Reviewed-by: Nicolas Schier Reviewed-by: Kees Cook Reviewed-by: Justin Stitt Signed-off-by: Masahiro Yamada [nathan: Fix silent conflict due to lack of 7d153696e5db in older trees] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman