kernel/linux.git/scripts, branch v6.13.2

kbuild: fix Clang LTO with CONFIG_OBJTOOL=n

2025-02-08T09:02:18+00:00

[ Upstream commit 695ed93bb30e03e9f826ee70abdd83f970741a37 ] Since commit bede169618c6 ("kbuild: enable objtool for *.mod.o and additional kernel objects"), Clang LTO builds do not perform any optimizations when CONFIG_OBJTOOL is disabled (e.g., for ARCH=arm64). This is because every LLVM bitcode file is immediately converted to ELF format before the object files are linked together. This commit fixes the breakage. Fixes: bede169618c6 ("kbuild: enable objtool for *.mod.o and additional kernel objects") Reported-by: Yonghong Song Signed-off-by: Masahiro Yamada Tested-by: Yonghong Song Signed-off-by: Sasha Levin

kconfig: fix memory leak in sym_warn_unmet_dep()

2025-02-08T09:02:18+00:00

[ Upstream commit a409fc1463d664002ea9bf700ae4674df03de111 ] The string allocated in sym_warn_unmet_dep() is never freed, leading to a memory leak when an unmet dependency is detected. Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable") Signed-off-by: Masahiro Yamada Reviewed-by: Petr Vorel Signed-off-by: Sasha Levin

kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST

2025-02-08T09:02:18+00:00

[ Upstream commit a314f52a0210730d0d556de76bb7388e76d4597d ] Most 'make *config' commands use .config as the base configuration file. When .config does not exist, Kconfig tries to load a file listed in KCONFIG_DEFCONFIG_LIST instead. However, since commit b75b0a819af9 ("kconfig: change defconfig_list option to environment variable"), warning messages have displayed an incorrect file name in such cases. Below is a demonstration using Debian Trixie. While loading /boot/config-6.12.9-amd64, the warning messages incorrectly show .config as the file name. With this commit, the correct file name is displayed in warnings. [Before] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # .config:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT .config:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC [After] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # /boot/config-6.12.9-amd64:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT /boot/config-6.12.9-amd64:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC Fixes: b75b0a819af9 ("kconfig: change defconfig_list option to environment variable") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: Fix signing issue for external modules

2025-02-08T09:02:16+00:00

[ Upstream commit 25ff08aa43e373a61c3e36fc7d7cae88ed0fc2d7 ] When running the sign script the kernel is within the source directory of external modules. This caused issues when the kernel uses relative paths, like: make[5]: Entering directory '/build/client/devel/kernel/work/linux-2.6' make[6]: Entering directory '/build/client/devel/addmodules/vtx/work/vtx' INSTALL /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+/extra/vtx.ko SIGN /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+/extra/vtx.ko /bin/sh: 1: scripts/sign-file: not found DEPMOD /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+ Working around it by using absolute pathes here. Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=") Signed-off-by: Torsten Hilbrich Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

genksyms: fix memory leak when the same symbol is read from *.symref file

2025-02-08T09:02:16+00:00

[ Upstream commit be2fa44b5180a1f021efb40c55fdf63c249c3209 ] When a symbol that is already registered is read again from *.symref file, __add_symbol() removes the previous one from the hash table without freeing it. [Test Case] $ cat foo.c #include void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); $ cat foo.symref foo void foo ( void ) foo void foo ( void ) When a symbol is removed from the hash table, it must be freed along with its ->name and ->defn members. However, sym->name cannot be freed because it is sometimes shared with node->string, but not always. If sym->name and node->string share the same memory, free(sym->name) could lead to a double-free bug. To resolve this issue, always assign a strdup'ed string to sym->name. Fixes: 64e6c1e12372 ("genksyms: track symbol checksum changes") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

genksyms: fix memory leak when the same symbol is added from source

2025-02-08T09:02:16+00:00

[ Upstream commit 45c9c4101d3d2fdfa00852274bbebba65fcc3cf2 ] When a symbol that is already registered is added again, __add_symbol() returns without freeing the symbol definition, making it unreachable. The following test cases demonstrate different memory leak points. [Test Case 1] Forward declaration with exactly the same definition $ cat foo.c #include void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 2] Forward declaration with a different definition (e.g. attribute) $ cat foo.c #include void foo(void); __attribute__((__section__(".ref.text"))) void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 3] Preserving an overridden symbol (compile with KBUILD_PRESERVE=1) $ cat foo.c #include void foo(void); void foo(void) { } EXPORT_SYMBOL(foo); $ cat foo.symref override foo void foo ( int ) The memory leaks in Test Case 1 and 2 have existed since the introduction of genksyms into the kernel tree. [1] The memory leak in Test Case 3 was introduced by commit 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes"). When multiple init_declarators are reduced to an init_declarator_list, the decl_spec must be duplicated. Otherwise, the following Test Case 4 would result in a double-free bug. [Test Case 4] $ cat foo.c #include extern int foo, bar; int foo, bar; EXPORT_SYMBOL(foo); In this case, 'foo' and 'bar' share the same decl_spec, 'int'. It must be unshared before being passed to add_symbol(). [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=46bd1da672d66ccd8a639d3c1f8a166048cca608 Fixes: 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/decode_stacktrace.sh: fix decoding of lines with an additional info

2025-01-13T03:03:34+00:00

Since commit bdf8eafbf7f5 ("arm64: stacktrace: report source of unwind data") a stack trace line can contain an additional info field that was not present before, in the form of one or more letters in parentheses. E.g.: [ 504.517915] led_sysfs_enable+0x54/0x80 (P) ^^^ When this is present, decode_stacktrace decodes the line incorrectly: [ 504.517915] led_sysfs_enable+0x54/0x80 P Extend parsing to decode it correctly: [ 504.517915] led_sysfs_enable (drivers/leds/led-core.c:455 (discriminator 7)) (P) The regex to match such lines assumes the info can be extended in the future to other uppercase characters, and will need to be extended in case other characters will be used. Using a much more generic regex might incur in false positives, so this looked like a good tradeoff. Link: https://lkml.kernel.org/r/20241230-decode_stacktrace-fix-info-v1-1-984910659173@bootlin.com Fixes: bdf8eafbf7f5 ("arm64: stacktrace: report source of unwind data") Signed-off-by: Luca Ceresoli Cc: Catalin Marinas Cc: Mark Brown Cc: Mark Rutland Cc: Miroslav Benes Cc: Puranjay Mohan Cc: Thomas Petazzoni Signed-off-by: Andrew Morton

Merge tag 'kbuild-fixes-v6.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2025-01-05T18:52:47+00:00

Pull Kbuild fixes from Masahiro Yamada: - Fix escaping of '$' in scripts/mksysmap - Fix a modpost crash observed with the latest binutils - Fix 'provides' in the linux-api-headers pacman package * tag 'kbuild-fixes-v6.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: pacman-pkg: provide versioned linux-api-headers package modpost: work around unaligned data access error modpost: refactor do_vmbus_entry() modpost: fix the missed iteration for the max bit in do_input() scripts/mksysmap: Fix escape chars '$'

kbuild: pacman-pkg: provide versioned linux-api-headers package

2025-01-05T14:19:17+00:00

The Arch Linux glibc package contains a versioned dependency on "linux-api-headers". If the linux-api-headers package provided by pacman-pkg does not specify an explicit version this dependency is not satisfied. Fix the dependency by providing an explicit version. Fixes: c8578539deba ("kbuild: add script and target to generate pacman package") Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada

scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivity

2024-12-31T01:59:11+00:00

The orc_sort_cmp() function, used with qsort(), previously violated the symmetry and transitivity rules required by the C standard. Specifically, when both entries are ORC_TYPE_UNDEFINED, it could result in both a < b and b < a, which breaks the required symmetry and transitivity. This can lead to undefined behavior and incorrect sorting results, potentially causing memory corruption in glibc implementations [1]. Symmetry: If x < y, then y > x. Transitivity: If x < y and y < z, then x < z. Fix the comparison logic to return 0 when both entries are ORC_TYPE_UNDEFINED, ensuring compliance with qsort() requirements. Link: https://www.qualys.com/2024/01/30/qsort.txt [1] Link: https://lkml.kernel.org/r/20241226140332.2670689-1-visitorckw@gmail.com Fixes: 57fa18994285 ("scripts/sorttable: Implement build-time ORC unwind table sorting") Fixes: fb799447ae29 ("x86,objtool: Split UNWIND_HINT_EMPTY in two") Signed-off-by: Kuan-Wei Chiu Cc: Ching-Chun (Jim) Huang Cc: Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Shile Zhang Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton