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/<pid>/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 ...
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 <ojeda@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Now that the Rust KUnit tests are protected with Kconfig, update the documentation to mention it. Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: David Gow <david@davidgow.net> Acked-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260417031531.315281-4-ynorov@nvidia.com [ Fixed the paragraph by moving the new sentence above. Added gate in the other example as well. Applied proper formatting. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Currently the example in the documentation shows a version-based name
for the Kconfig example:
RUSTC_VERSION_MIN_107900
The reason behind it was to possibly avoid repetition in case several
features used the same minimum.
However, we ended up preferring to give them a descriptive name for each
feature added even if that could lead to some repetition. In practice,
the repetition has not happened so far, and even if it does at some point,
it is not a big deal.
Thus replace the example in the documentation with one of our current
examples (after removing previous ones from the bump), to show how they
actually look like, and in case someone `grep`s for it.
In addition, it has the advantage that it shows the `RUSTC_HAS_*`
pattern we follow in `init/Kconfig`, similar to the C side.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-31-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
There is no need to use `def_bool y if <expr>` -- one can simply write `def_bool <expr>`. In fact, the simpler form is how we actually use them in practice in `init/Kconfig`. Thus simplify the example. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-30-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1]. Thus remove the workaround. Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable. So we are at the point where keeping the docs short and relevant for essentially everyone is probably the better trade-off. Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1] Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-29-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2]. Thus remove it to simplify the documentation. Link: https://search.nixos.org/packages?channel=25.11&query=rust [1] Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-28-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Gentoo does not need the "testing" note, since its packages are recent enough even in the stable branch [1][2]. Thus remove it to simplify the documentation. Link: https://packages.gentoo.org/packages/dev-lang/rust [1] Link: https://packages.gentoo.org/packages/dev-util/bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-27-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu 25.10 has [2][3]. We could update the title and the paragraph, but to simplify and to make it more consistent with the other distributions' sections, let's instead just remove that title. It will also reduce the differences later on to keep it updated. Eventually, when we remove the remaining subsection for older LTSs, Ubuntu should be a small section like the other distributions. Thus remove the title and add the mention of Ubuntu 26.04 LTS. Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2] Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all§ion=all [3] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-26-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest supported one. Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust given the minimum bump -- they provide 1.85.1 [2]. Thus update it. Link: https://ubuntu.com/about/release-cycle [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-25-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>