kernel/linux.git/scripts, branch v7.0.13

rust: kasan/kbuild: fix rustc-option when cross-compiling

2026-06-19T11:47:57+00:00

commit 4a44b17406cb5a93f90af3df9392b3a45eb336fb upstream. The Makefile version of rustc-option currently checks whether the option exists for the host target instead of the target actually being compiled for. It was done this way in commit 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") to avoid a circular dependency on target.json. However, because of this, rustc-option currently does not function when cross-compiling from x86_64 to aarch64 if CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS contains -Zfixed-x18 under this configuration. Since that flag does not exist on the host target, rustc-option runs into a compilation failure every time, leading to all flags being rejected as unsupported. To fix this, update rustc-option to pass a --target parameter so that the host target is not used. For targets using target.json, use a built-in target that is as close as possible to the target created with target.json to avoid the circular dependency on target.json. One scenario where this causes a boot failure: * Cross-compiled from x86_64 to aarch64. * With CONFIG_SHADOW_CALL_STACK=y * With CONFIG_KASAN_SW_TAGS=y * With CONFIG_KASAN_INLINE=n Then the resulting kernel image will fail to boot when it first calls into Rust code with a crash along the lines of "Unable to handle kernel paging request at virtual address 0ffffffc08541796". This is because the call threshold is not specified, so rustc will inline kasan operations, but the kasan shadow offset is not specified, which leads to the inlined kasan instructions being incorrect. Note that the -Zsanitizer=kernel-hwaddress parameter itself does not lead to a rustc-option failure despite being aarch64-specific because RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when rustc-option is evaluated by the kasan Makefile. Cc: stable@vger.kernel.org Fixes: 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260507-rustc-option-cross-v2-1-2f650a49c2b5@google.com [ Edited slightly: - Reset variable to avoid using the environment. - Use a simply expanded variable flavor for simplicity. - Export variable so that behavior in sub-`make`s is consistent. Signed-off-by: Greg Kroah-Hartman This matches other variables. - Miguel ] Signed-off-by: Miguel Ojeda

rust: x86: support Rust >= 1.98.0 target spec

2026-06-19T11:47:57+00:00

commit 905b06d32a52afe32fcf5f30cf298c9ea6359f11 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), the target spec will not support `x86-softfloat` anymore [1]. Instead, `softfloat` should be used, which is an alias. Otherwise, one gets: error: error loading target specification: rustc-abi: invalid rustc abi: 'x86-softfloat'. allowed values: 'x86-sse2', 'softfloat' at line 3 column 32 | = help: run `rustc --print target-list` for a list of built-in targets Thus conditionally use one or the other depending on the version. The alias has existed since Rust 1.95.0 (released 2026-04-16) [2], but use the newer version instead to avoid changing how the build works for existing compilers, at least until more testing takes place. Cc: Ralf Jung Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/157151 [1] Link: https://github.com/rust-lang/rust/pull/151154 [2] Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260530114925.260754-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme

2026-06-01T15:54:48+00:00

[ Upstream commit 202550713128da20d9381d6d2dc0f6b73839f434 ] The package versioning scheme does not enable smooth upgrades from "rc" releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0) because pacman considers that a downgrade due to the underscore in pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the package version comparison used by pacman. Package versions which are derived from said releases (e.g. built from git revisions) are similarly affected. Fix this by modifying pkgver in order to remove the hyphen from kernel versions containing "-rcN", where N is a non-negative integer. Acked-by: Thomas Weißschuh Signed-off-by: Viktor Jägersküpper Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://patch.msgid.link/20260515215913.92481-1-viktor_jaegerskuepper@freenet.de Fixes: c8578539deba ("kbuild: add script and target to generate pacman package") Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin

gcc-plugins: Always define CONST_CAST_GIMPLE and CONST_CAST_TREE

2026-06-01T15:54:44+00:00

[ Upstream commit 905c559e51497b8bfdbb68df8be56d2f70f0de8e ] For gcc-16, the CONST_CAST macro family was removed. Add back what we were using in gcc-common.h, as they are simple wrappers. See GCC commits: c3d96ff9e916c02584aa081f03ab999292efbb50 458c7926d48959abcb2c1adaa22458e27459a551 Suggested-by: Ingo Saitz Link: https://lore.kernel.org/lkml/ab6OKoay0OWkywjK@spatz.zoo Fixes: 6b90bd4ba40b ("GCC plugin infrastructure") Tested-by: Ivan Bulatovic Tested-by: Christopher Cradock Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

scripts/gdb: mm: cast untyped symbols in x86_page_ops

2026-06-01T15:54:20+00:00

commit c416aee7e7d04fec2d2d30786b3c8393108b85d2 upstream. The symbols phys_base, _text, and _end, used in x86_page_ops are either defined in assembly or implicitly by the linker. Thus, they lack type information and cause a conversion error after gdb.parse_and_eval. Explicitly cast these expressions to unsigned long. Link: https://lore.kernel.org/20260427142448.666117-2-illia@yshyn.com Fixes: 55f8b4518d14 ("scripts/gdb: implement x86_page_ops in mm.py") Signed-off-by: Illia Ostapyshyn Cc: Florian Fainelli Cc: Jan Kiszka Cc: Kieran Bingham Cc: Vlastimil Babka Cc: Hao Li Cc: Harry Yoo Cc: Seongjun Hong Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

kbuild: builddeb - avoid recompiles for non-cross-compiles

2026-05-23T11:09:24+00:00

[ Upstream commit 2452dcf4d740effff5aa71b7f6529ee8c04fd8f6 ] Commit e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") changed how install-extmod-build gets called, making it always rebuild the host programs below scripts/ if HOSTCC wasn't specified with its full triplet on the make command line. That is, apparently, needed to fix up commit f1d87664b82a ("kbuild: cross-compile linux-headers package when possible") for cross-compiles. However, in the much more common case of non-cross-compile builds this will lead to unnecessary rebuilding of host tools including gcc plugins. This, in turn, will lead to a full kernel rebuild on the next 'make bindeb-pkg' which is unfortunate. Avoid that by only triggering the rebuild of host tools for actual cross-compile builds. Signed-off-by: Mathias Krause Fixes: e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") Cc: Masahiro Yamada Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260402145116.1010901-1-minipli@grsecurity.net Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin

scripts/gdb: timerlist: Adapt to move of tk_core

2026-05-23T11:08:29+00:00

[ Upstream commit 5aa9383813aca45b914d4a7481ca417ef13114df ] tk_core is a macro today which cannot be resolved by gdb. Use the correct symbol expression to reference tk_core. Fixes: 22c62b9a84b8 ("timekeeping: Introduce auxiliary timekeepers") Signed-off-by: Thomas Weißschuh (Schneider Electric) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260311-hrtimer-cleanups-v1-1-095357392669@linutronix.de Signed-off-by: Sasha Levin

check-uapi: link into shared objects

2026-05-07T04:14:09+00:00

commit a261f6dff3c1653c19c065c3b3650c625447b8a7 upstream. While testing ABI changes across all architectures, I found that abidiff sometimes produces nonsensical output. Further debugging identified missing or broken libelf support for architecture specific relocations in ET_REL binaries as the source of the problem[1]. Change the script to no longer produce a relocatable object file but instead create a shared library for each header. This makes abidiff work for all of the architectures in upstream linux kernels. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33869 Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Weißschuh Acked-by: Nathan Chancellor Link: https://patch.msgid.link/20260306163309.2015837-2-arnd@kernel.org Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman

module.lds.S: Fix modules on 32-bit parisc architecture

2026-05-07T04:13:54+00:00

commit 1221365f55281349da4f4ba41c05b57cd15f5c28 upstream. On the 32-bit parisc architecture, we always used the -ffunction-sections compiler option to tell the compiler to put the functions into seperate text sections. This is necessary, otherwise "big" kernel modules like ext4 or ipv6 fail to load because some branches won't be able to reach their stubs. Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") broke this for parisc because all text sections will get unconditionally merged now. Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which avoids the text section merge for modules, and fix this issue by enabling this option by default for 32-bit parisc. Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Cc: Josh Poimboeuf Cc: stable@vger.kernel.org # v6.19+ Suggested-by: Sami Tolvanen Reviewed-by: Petr Pavlu Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

module.lds,codetag: force 0 sh_addr for sections

2026-05-07T04:13:54+00:00

commit 4afc71bba8b7d7841681e7647ae02f5079aaf28f upstream. Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") added .text and made .data, .bss, and .rodata sections unconditional in the module linker script, but without an explicit address like the other sections in the same file. When linking modules with ld.bfd -r, sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the .ko. Relocatable objects are expected to have sh_addr=0 for these sections and these non-zero addresses confuse elfutils and have been reported to cause segmentation faults in SystemTap [1]. Add the 0 address specifier to all sections in module.lds, including the .codetag.* sections via MOD_SEPARATE_CODETAG_SECTIONS macro. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Signed-off-by: Joe Lawrence Reviewed-by: Petr Pavlu Acked-by: Josh Poimboeuf Signed-off-by: Sami Tolvanen Signed-off-by: Greg Kroah-Hartman