kernel/linux.git/scripts/min-tool-version.sh, branch v7.2-rc1

Merge tag 's390-7.2-1' of gitolite.kernel.org:pub/scm/linux/kernel/git/s390/linux

2026-06-15T23:38:13+00:00

Pull s390 updates from Alexander Gordeev: - Use CIO device online variable instead of the internal FSM state to determine device availability during purge operations - Remove extra check of task_stack_page() because try_get_task_stack() already takes care of that when reading /proc//wchan - Allow user-space to use the new SCLP action qualifier 4 for to provide NVMe SMART log data to the platform. - Send AP CHANGE uevents on successful bind and successful association to notify user-space about SE operations on AP queue devices - Add an s390dbf kernel parameter to configure debug log levels and area sizes during early boot - On arm64 the empty zero page is going to be mapped read-only. Do the same for s390 with an explicit set_memory_ro() call - Improve s390-specific bcr_serialize() and cpu_relax() implementations - Remove all unused variables to avoid allmodconfig W=1 build fails with latest clang-23 - Cleanup default Kconfig values for s390 selftests - Add a s390-tod trace clock to allow comparing trace timestamps between different systems or virtual machines on s390 - Remove the s390 implementation of strlcat() in favor of the generic variant - Make consistent the calling order between page_table_check_pte_clear() and secure page conversion across all code paths - Rearrange some fields within AP and zcrypt structs to reduce memory consumption and unused holes - Shorten GR_NUM and VX_NUM macros and move them to a separate header - Replace __get_free_page() with kmalloc() in few sources - Introduce an infrastructure for more efficient this_cpu operations. Eliminate conditional branches when PREEMPT_NONE is removed - Enable Rust support - Use z10 as minimum architecture level, similar to the boot code, to enforce a defined architecture level set - Improve and convert various mem*() helper functions to C. For that add .noinstr.text section to avoid orphaned warnings from the linker - Fix the function pointer type in __ret_from_fork() to correct the indirect call to match kernel thread return type of int - Revert support for DCACHE_WORD_ACCESS to avoid an endless exception loop on read from donated Ultravisor pages at unaligned addresses * tag 's390-7.2-1' of gitolite.kernel.org:pub/scm/linux/kernel/git/s390/linux: (52 commits) s390: Revert support for DCACHE_WORD_ACCESS s390/process: Fix kernel thread function pointer type s390/tishift: Convert __ashlti3(), __ashrti3(), __lshrti3() to C s390/memmove: Optimize backward copy case s390/string: Convert memset(16|32|64)() to C s390/string: Convert memcpy() to C s390/string: Convert memset() to C s390/string: Convert memmove() to C s390/string: Add -ffreestanding compile option to string.o s390: Add .noinstr.text to boot and purgatory linker scripts s390/purgatory: Enforce z10 minimum architecture level s390: Enable Rust support s390/cmpxchg: Fix KASAN stack-out-of-bounds in atomic helpers rust: helpers: Add memchr wrapper for string operations rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support s390/ap: Fix locking issue in SE bind and associate sysfs functions s390/percpu: Provide arch_this_cpu_write() implementation s390/percpu: Provide arch_this_cpu_read() implementation ...

s390: Enable Rust support

2026-06-10T14:25:13+00:00

Enable building Rust code on s390 by wiring the architecture into the kernel Rust infrastructure. Add s390 to the Rust arch support documentation, provide the s390 Rust target and required compiler flags, and set the bindgen target for arch/s390. Adjust the Rust target generation and minimum rustc version gating so the s390 setup is handled explicitly. The Rust toolchain uses the "s390x" triple naming for the 64 bit target. Rust support is currently incompatible with CONFIG_EXPOLINE, which relies on compiler support for the -mindirect-branch= and -mfunction_return= options. Therefore, select HAVE_RUST only when EXPOLINE is disabled. Acked-by: Miguel Ojeda Acked-by: Gary Guo Acked-by: Heiko Carstens Signed-off-by: Jan Polensky Signed-off-by: Alexander Gordeev

kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1

2026-05-27T22:18:53+00:00

The current minimum version of LLVM for building the kernel is 15.0.0. However, there are two deficiencies compared to GCC that were fixed in LLVM 17 that are starting to become more noticeable. The first was a bug in LLVM's scope checker [1], where all labels in a function were validated as potential targets of an asm goto statement, even if they were not listed in the asm goto statement as targets. This becomes particularly problematic when the cleanup attribute is used, as asm goto(... : label_a); ... label_a: ... int var __free(foo); asm goto(... : label_b); ... label_b: ... will trigger an error since the scope checker will complain that the cleanup variable would be skipped when jumping from the first asm goto to label_b (which obviously cannot happen). This issue was the catalyst for commit e2ffa15b9baa ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on clang < 17"). Unfortunately, this issue is reproducible with regular asm goto in addition to asm goto with outputs, so that change was not entirely sufficient to avoid the issue altogether. As asm goto has effectively been required since commit a0a12c3ed057 ("asm goto: eradicate CC_HAS_ASM_GOTO") and the usage of the cleanup attribute continues to grow across the tree, raising the minimum to a version that avoids this issue altogether is a better long term solution than attempting to workaround it at every spot where it happens. The second issue is an incompatibility with GCC 8.1+ around variables marked with const being valid constant expressions for _Static_assert and other macros [2]. With GCC 8.1 being the minimum supported version since commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30"), this incompatibility becomes more of a maintenance burden since only clang-15 and clang-16 are affected by it. Looking at the clang version of various major distributions through Docker images, no one should be left behind as a result of this bump, as the old ones cannot clear the current minimum of 15.0.0. archlinux:latest clang version 22.1.3 debian:oldoldstable-slim Debian clang version 11.0.1-2 debian:oldstable-slim Debian clang version 14.0.6 debian:stable-slim Debian clang version 19.1.7 (3+b1) debian:testing-slim Debian clang version 21.1.8 (3+b1) debian:unstable-slim Debian clang version 21.1.8 (7+b1) fedora:42 clang version 20.1.8 (Fedora 20.1.8-4.fc42) fedora:latest clang version 21.1.8 (Fedora 21.1.8-4.fc43) fedora:44 clang version 22.1.1 (Fedora 22.1.1-2.fc44) fedora:rawhide clang version 22.1.3 (Fedora 22.1.3-1.fc45) opensuse/leap:latest clang version 17.0.6 opensuse/tumbleweed:latest clang version 21.1.8 ubuntu:jammy Ubuntu clang version 14.0.0-1ubuntu1.1 ubuntu:noble Ubuntu clang version 18.1.3 (1ubuntu1) ubuntu:questing Ubuntu clang version 20.1.8 (0ubuntu4) ubuntu:resolute Ubuntu clang version 21.1.8 (6ubuntu1) 17.0.1 is chosen as the minimum instead of 17.0.0 to ensure that the particular version of LLVM 17 has the two aforementioned bugs fixed, as the second was fixed during the 17.0.0 release candidate phase and it was not until LLVM 18 that LLVM adopted the scheme of x.0.0 being a prerelease version and x.1.0 is a release version [3] to help with scenarios such as this. Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14 [1] Link: https://github.com/llvm/llvm-project/commit/0b2d5b967d98375793897295d651f58f6fbd3034 [2] Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [3] Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-1-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor

rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)

2026-04-07T08:00:24+00:00

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's `bindgen` versions as our minimum supported version. Debian Trixie was released with `bindgen` 0.71.1, which it still uses to this day [2]. Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://packages.debian.org/trixie/bindgen [2] Link: https://www.debian.org/releases/trixie/ [3] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5] Acked-by: Tamir Duberstein Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260405235309.418950-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)

2026-04-07T07:51:39+00:00

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version. Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1). Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those. Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION` tests can also be updated, but there are no suitable ones to simplify. Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://www.debian.org/releases/trixie/ [4] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6] Acked-by: Tamir Duberstein Acked-by: Benno Lossin Acked-by: Gary Guo Acked-by: Danilo Krummrich Acked-by: Alice Ryhl Link: https://patch.msgid.link/20260405235309.418950-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda

kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0

2025-08-28T23:58:43+00:00

s390 and x86 have required LLVM 15 since 30d17fac6aae ("scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390") 7861640aac52 ("x86/build: Raise the minimum LLVM version to 15.0.0") respectively but most other architectures allow LLVM 13.0.1 or newer. In accordance with the recent minimum supported version of GCC bump that happened in 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") do the same for LLVM to 15.0.0. Of the supported releases of Arch Linux, Debian, Fedora, and OpenSUSE surveyed in evaluating this bump, this only leaves behind Debian Bookworm (14.0.6) and Ubuntu Jammy (14.0.0). Debian Trixie has 19.1.7 and Ubuntu Noble has 18.1.3 (so there are viable upgrade paths) or users can use apt.llvm.org, which provides even newer packages for those distributions. Reviewed-by: Kees Cook Acked-by: Arnd Bergmann Acked-by: Nicolas Schier Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-1-635f3294e5f0@kernel.org Signed-off-by: Nathan Chancellor

kbuild: require gcc-8 and binutils-2.30

2025-04-30T19:53:35+00:00

Commit a3e8fe814ad1 ("x86/build: Raise the minimum GCC version to 8.1") raised the minimum compiler version as enforced by Kbuild to gcc-8.1 and clang-15 for x86. This is actually the same gcc version that has been discussed as the minimum for all architectures several times in the past, with little objection. A previous concern was the kernel for SLE15-SP7 needing to be built with gcc-7. As this ended up still using linux-6.4 and there is no plan for an SP8, this is no longer a problem. Change it for all architectures and adjust the documentation accordingly. A few version checks can be removed in the process. The binutils version 2.30 is the lowest version used in combination with gcc-8 on common distros, so use that as the corresponding minimum. Link: https://lore.kernel.org/lkml/20240925150059.3955569-32-ardb+git@google.com/ Link: https://lore.kernel.org/lkml/871q7yxrgv.wl-tiwai@suse.de/ Acked-by: Mark Rutland Signed-off-by: Arnd Bergmann

x86/build: Raise the minimum LLVM version to 15.0.0

2025-02-21T13:08:16+00:00

In a similar vein as to this pending commit in the x86/asm tree: a3e8fe814ad1 ("x86/build: Raise the minimum GCC version to 8.1") ... bump the minimum supported version of LLVM for building x86 kernels to 15.0.0, as that is the first version that has support for '-mstack-protector-guard-symbol', which is used unconditionally after: 80d47defddc0 ("x86/stackprotector/64: Convert to normal per-CPU variable"): Older Clang versions will fail the build with: clang-14: error: unknown argument: '-mstack-protector-guard-symbol=__ref_stack_chk_guard' Fixes: 80d47defddc0 ("x86/stackprotector/64: Convert to normal per-CPU variable") Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Cc: Linus Torvalds Reviewed-by: Ard Biesheuvel Reviewed-by: Brian Gerst Link: https://lore.kernel.org/r/20250220-x86-bump-min-llvm-for-stackp-v1-1-ecb3c906e790@kernel.org

x86/build: Raise the minimum GCC version to 8.1

2025-02-18T09:14:40+00:00

Stack protector support on 64-bit currently requires that the percpu section is linked at absolute address 0, because older compilers fixed the location of the canary value relative to the GS segment base. GCC 8.1 introduced options to change where the canary value is located, allowing it to be configured as a standard per-CPU variable. This has already been done for 32-bit. Doing the same for 64-bit will enable removing the code needed to support zero-based percpu. Signed-off-by: Brian Gerst Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250123190747.745588-2-brgerst@gmail.com

rust: upgrade to Rust 1.78.0

2024-05-05T18:17:25+00:00

This is the next upgrade to the Rust toolchain, from 1.77.1 to 1.78.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). It is much smaller than previous upgrades, since the `alloc` fork was dropped in commit 9d0441bab775 ("rust: alloc: remove our fork of the `alloc` crate") [3]. # Unstable features There have been no changes to the set of unstable features used in our own code. Therefore, the only unstable features allowed to be used outside the `kernel` crate is still `new_uninit`. However, since we finally dropped our `alloc` fork [3], all the unstable features used by `alloc` (~30 language ones, ~60 library ones) are not a concern anymore. This reduces the maintenance burden, increases the chances of new compiler versions working without changes and gets us closer to the goal of supporting several compiler versions. It also means that, ignoring non-language/library features, we are currently left with just the few language features needed to implement the kernel `Arc`, the `new_uninit` library feature, the `compiler_builtins` marker and the few `no_*` `cfg`s we pass when compiling `core`/`alloc`. Please see [4] for details. # Required changes ## LLVM's data layout Rust 1.77.0 (i.e. the previous upgrade) introduced a check for matching LLVM data layouts [5]. Then, Rust 1.78.0 upgraded LLVM's bundled major version from 17 to 18 [6], which changed the data layout in x86 [7]. Thus update the data layout in our custom target specification for x86 so that the compiler does not complain about the mismatch: error: data-layout for target `target-5559158138856098584`, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128`, differs from LLVM target's `x86_64-linux-gnu` default layout, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128` In the future, the goal is to drop the custom target specifications. Meanwhile, if we want to support other LLVM versions used in `rustc` (e.g. for LTO), we will need to add some extra logic (e.g. conditional on LLVM's version, or extracting the data layout from an existing built-in target specification). ## `unused_imports` Rust's `unused_imports` lint covers both unused and redundant imports. Now, in 1.78.0, the lint detects more cases of redundant imports [8]. Thus one of the previous patches cleaned them up. ## Clippy's `new_without_default` Clippy now suggests to implement `Default` even when `new()` is `const`, since `Default::default()` may call `const` functions even if it is not `const` itself [9]. Thus one of the previous patches implemented it. # Other changes in Rust Rust 1.78.0 introduced `feature(asm_goto)` [10] [11]. This feature was discussed in the past [12]. Rust 1.78.0 introduced `feature(const_refs_to_static)` [13] to allow referencing statics in constants and extended `feature(const_mut_refs)` to allow raw mutable pointers in constants. Together, this should cover the kernel's `VTABLE` use case. In fact, the implementation [14] in upstream Rust added a test case for it [15]. Rust 1.78.0 with debug assertions enabled (i.e. `-Cdebug-assertions=y`, kernel's `CONFIG_RUST_DEBUG_ASSERTIONS=y`) now always checks all unsafe preconditions, though without a way to opt-out for particular cases [16]. It would be ideal to have a way to selectively disable certain checks per-call site for this one (i.e. not just per check but for particular instances of a check), even if the vast majority of the checks remain in place [17]. Rust 1.78.0 also improved a couple issues we reported when giving feedback for the new `--check-cfg` feature [18] [19]. # `alloc` upgrade and reviewing As mentioned above, compiler upgrades will not update `alloc` anymore, since we dropped our `alloc` fork [3]. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1780-2024-05-02 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://lore.kernel.org/rust-for-linux/20240328013603.206764-1-wedsonaf@gmail.com/ [3] Link: https://github.com/Rust-for-Linux/linux/issues/2 [4] Link: https://github.com/rust-lang/rust/pull/120062 [5] Link: https://github.com/rust-lang/rust/pull/120055 [6] Link: https://reviews.llvm.org/D86310 [7] Link: https://github.com/rust-lang/rust/pull/117772 [8] Link: https://github.com/rust-lang/rust-clippy/pull/10903 [9] Link: https://github.com/rust-lang/rust/pull/119365 [10] Link: https://github.com/rust-lang/rust/issues/119364 [11] Link: https://lore.kernel.org/rust-for-linux/ZWipTZysC2YL7qsq@Boquns-Mac-mini.home/ [12] Link: https://github.com/rust-lang/rust/issues/119618 [13] Link: https://github.com/rust-lang/rust/pull/120932 [14] Link: https://github.com/rust-lang/rust/pull/120932/files#diff-e6fc1622c46054cd46b1d225c5386c5554564b3b0fa8a03c2dc2d8627a1079d9 [15] Link: https://github.com/rust-lang/rust/issues/120969 [16] Link: https://github.com/Rust-for-Linux/linux/issues/354 [17] Link: https://github.com/rust-lang/rust/pull/121202 [18] Link: https://github.com/rust-lang/rust/pull/121237 [19] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240401212303.537355-4-ojeda@kernel.org [ Added a few more details and links I mentioned in the list. - Miguel ] Signed-off-by: Miguel Ojeda