[PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Jan Polensky]

Rust support on s390 requires a small set of architecture-specific pieces
before the generic Rust kernel infrastructure can be used.

The series wires up s390 as a Rust-capable 64-bit architecture, adds the
missing assembly interfaces needed by Rust for WARN/BUG reporting and for
static branches, and adjusts bindgen parameters to avoid repr layout
conflicts caused by packed and aligned s390 structures.

s390 currently requires a rustc due to -Zpacked-stack, and the
minimum tool version gating is adjusted accordingly.

Link: https://github.com/Rust-for-Linux/linux/issues/2

Tested against: rustc 1.96.0-beta.7 (6be5f81e1 2026-05-17)

Changes since v2:
- mflags: cleanup (thanks Gary)
Changes since v1:
- strip the -nightly suffix in min-tool-version.sh (thanks miguel and alice)
- ARCH_JUMP_TABLE_ENTRY() moved up to align comments properly (thanks Gary)
- removed MONCODE_BUG to prevent 0U in non-C context in assembler (noted by Sashiko - AI)
- prevent environment pollution by explicit initialization mflag := (noted by Sashiko - AI)


Jan Polensky (4):
  s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support
  s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and
    ARCH_STATIC_BRANCH_ASM macros
  rust/bindgen_parameters: Mark s390 types as opaque to prevent repr
    conflicts
  s390: Enable Rust support

 Documentation/rust/arch-support.rst |  1 +
 arch/s390/Kconfig                   |  1 +
 arch/s390/Makefile                  | 28 ++++++++++++++----------
 arch/s390/include/asm/bug.h         | 12 +++++++++++
 arch/s390/include/asm/jump_label.h  | 33 +++++++++++++++++------------
 rust/Makefile                       |  1 +
 rust/bindgen_parameters             |  7 ++++++
 scripts/generate_rust_target.rs     |  2 ++
 scripts/min-tool-version.sh         |  6 +++++-
 9 files changed, 65 insertions(+), 26 deletions(-)


base-commit: 758c807bb943138f887d42d986b645e12446ba9c
--
2.51.0

[PATCH v3 1/4] s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support

[Jan Polensky]

Rust WARN and BUG support relies on ARCH_WARN_ASM to emit __bug_table
entries. On s390 the macro is missing, so Rust code cannot generate
proper WARN/BUG metadata for the kernel's bug reporting infrastructure.

Define ARCH_WARN_ASM to produce the same assembly sequence and
__bug_table entry format as the existing s390 BUG handling, including
the monitor call. Define ARCH_WARN_REACHABLE as empty since s390 does
not provide reachability analysis for warning paths.

Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 arch/s390/include/asm/bug.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/s390/include/asm/bug.h b/arch/s390/include/asm/bug.h
index 59017fd3d935..a72439370f62 100644
--- a/arch/s390/include/asm/bug.h
+++ b/arch/s390/include/asm/bug.h
@@ -4,6 +4,7 @@
 
 #include <linux/compiler.h>
 #include <linux/const.h>
+#include <linux/stringify.h>
 
 #define	MONCODE_BUG	_AC(0, U)
 #define	MONCODE_BUG_ARG _AC(1, U)
@@ -121,6 +122,17 @@ do {									\
 #define HAVE_ARCH_BUG_FORMAT
 #define HAVE_ARCH_BUG_FORMAT_ARGS
 
+#define ARCH_WARN_ASM(file, line, flags, size)				\
+	".section .rodata.str,\"aMS\",@progbits,1\n"			\
+	"9:\n"								\
+	".asciz \"\"\n"		/* Empty string for compatibility */	\
+	".previous\n"							\
+	"0:\n"								\
+	__stringify(mc 0(%r0),0) "\n"				\
+	__BUG_ENTRY("9b", file, line, flags, size)
+
+#define ARCH_WARN_REACHABLE
+
 #endif /* CONFIG_BUG && CONFIG_CC_HAS_ASM_IMMEDIATE_STRINGS */
 #endif /* __ASSEMBLER__ */
 
-- 
2.51.0

Re: [PATCH v3 1/4] s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support

[Gary Guo]

On Thu May 21, 2026 at 5:56 PM BST, Jan Polensky wrote:
> Rust WARN and BUG support relies on ARCH_WARN_ASM to emit __bug_table
> entries. On s390 the macro is missing, so Rust code cannot generate
> proper WARN/BUG metadata for the kernel's bug reporting infrastructure.
> 
> Define ARCH_WARN_ASM to produce the same assembly sequence and
> __bug_table entry format as the existing s390 BUG handling, including
> the monitor call. Define ARCH_WARN_REACHABLE as empty since s390 does
> not provide reachability analysis for warning paths.
> 
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>

Acked-by: Gary Guo <gary@garyguo.net>

> ---
>  arch/s390/include/asm/bug.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

[PATCH v3 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Jan Polensky]

Rust static branch support needs the s390 jump label instruction sequence
and __jump_table emission in a reusable form. The current implementation
embeds the sequence directly in the C asm goto blocks, which cannot be
shared with Rust.

Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
describe the brcl sequences for the likely-false and likely-true cases
and to emit the same __jump_table entries as before. Switch the existing
C helpers to use the new macros to avoid duplication without changing
the generated code.

Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
index d9cbc18f6b2e..0e28c90dc242 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -19,19 +19,29 @@
 #define JUMP_LABEL_STATIC_KEY_CONSTRAINT "jdd"
 #endif
 
+#define ARCH_JUMP_TABLE_ENTRY(key, label, local_label)	\
+	".pushsection __jump_table,\"aw\"\n"		\
+	".balign	8\n"				\
+	".long	" local_label "-.," label "-.\n"	\
+	".quad	" key "-.\n"				\
+	".popsection\n"
+
 /*
  * We use a brcl 0,<offset> instruction for jump labels so it
  * can be easily distinguished from a hotpatch generated instruction.
  */
+#define ARCH_STATIC_BRANCH_ASM(key, label)	\
+	"0:	brcl 0," label "\n"		\
+	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
+#define ARCH_STATIC_BRANCH_JUMP_ASM(key, label)	\
+	"0:	brcl 15," label "\n"		\
+	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
 static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
 {
-	asm goto("0:	brcl 0,%l[label]\n"
-			  ".pushsection __jump_table,\"aw\"\n"
-			  ".balign	8\n"
-			  ".long	0b-.,%l[label]-.\n"
-			  ".quad	%0+%1-.\n"
-			  ".popsection\n"
-			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+	asm goto(ARCH_STATIC_BRANCH_ASM("%0+%1", "%l[label]")
+		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
 	return false;
 label:
 	return true;
@@ -39,13 +49,8 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
 
 static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
 {
-	asm goto("0:	brcl 15,%l[label]\n"
-			  ".pushsection __jump_table,\"aw\"\n"
-			  ".balign	8\n"
-			  ".long	0b-.,%l[label]-.\n"
-			  ".quad	%0+%1-.\n"
-			  ".popsection\n"
-			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+	asm goto(ARCH_STATIC_BRANCH_JUMP_ASM("%0+%1", "%l[label]")
+		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
 	return false;
 label:
 	return true;
-- 
2.51.0

Re: [PATCH v3 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Alice Ryhl]

On Thu, May 21, 2026 at 06:56:20PM +0200, Jan Polensky wrote:
> Rust static branch support needs the s390 jump label instruction sequence
> and __jump_table emission in a reusable form. The current implementation
> embeds the sequence directly in the C asm goto blocks, which cannot be
> shared with Rust.
> 
> Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
> describe the brcl sequences for the likely-false and likely-true cases
> and to emit the same __jump_table entries as before. Switch the existing
> C helpers to use the new macros to avoid duplication without changing
> the generated code.
> 
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>

This looks right.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Did you test it?

Alice

Re: [PATCH v3 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Jan Polensky]

[-- Attachment #1: Type: text/plain, Size: 2937 bytes --]

On Wed, May 27, 2026 at 05:57:58AM +0000, Alice Ryhl wrote:
> On Thu, May 21, 2026 at 06:56:20PM +0200, Jan Polensky wrote:
> > Rust static branch support needs the s390 jump label instruction sequence
> > and __jump_table emission in a reusable form. The current implementation
> > embeds the sequence directly in the C asm goto blocks, which cannot be
> > shared with Rust.
> >
> > Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
> > describe the brcl sequences for the likely-false and likely-true cases
> > and to emit the same __jump_table entries as before. Switch the existing
> > C helpers to use the new macros to avoid duplication without changing
> > the generated code.
> >
> > Signed-off-by: Jan Polensky <japo@linux.ibm.com>
>
> This looks right.
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>
> Did you test it?
>
> Alice

Hi Alice,

yes, I tested it.

I used a small Rust sample module to exercise and validate the
behavior on s390. The patch is attached for reference. I did not
include the sample in this series.

It was not only rust I've used, my samples are not part of this series
(attached):

    ❯ readelf -SW samples/rust/rust_jump_label.ko | egrep '__jump_table|text|rela'
      [ 2] .rela__ksymtab    RELA            0000000000000000 06c298 000048 18   I 46   1  8
      [ 5] __jump_table      PROGBITS        0000000000000000 000060 000010 00  WA  0   0  8
      [ 6] .rela__jump_table RELA            0000000000000000 06c2e0 000048 18   I 46   5  8
      [ 7] .text             PROGBITS        0000000000000000 000070 0001bc 00  AX  0   0 16
      [ 8] .rela.text        RELA            0000000000000000 06c328 000228 18   I 46   7  8
      [ 9] .exit.text        PROGBITS        0000000000000000 000230 00003c 00  AX  0   0 16
      [10] .rela.exit.text   RELA            0000000000000000 06c550 000060 18   I 46   9  8
      [11] .init.text        PROGBITS        0000000000000000 000270 000026 00  AX  0   0 16
      [12] .rela.init.text   RELA            0000000000000000 06c5b0 000018 18   I 46  11  8
      [16] .rela.gnu.linkonce.this_module RELA            0000000000000000 06c5c8 000030 18   I 46  15  8
      [20] .rela.init.data   RELA            0000000000000000 06c5f8 000018 18   I 46  19  8
      [22] .rela.exit.data   RELA            0000000000000000 06c610 000018 18   I 46  21  8
      [32] .rela.debug_aranges RELA            0000000000000000 06c628 000108 18   I 46  31  8
      [34] .rela.debug_info  RELA            0000000000000000 06c730 0573f0 18   I 46  33  8
      [37] .rela.debug_line  RELA            0000000000000000 0c3b20 000048 18   I 46  36  8
      [39] .rela.debug_frame RELA            0000000000000000 0c3b68 000120 18   I 46  38  8
      [42] .rela.debug_loc   RELA            0000000000000000 0c3c88 000150 18   I 46  41  8
      [44] .rela.debug_ranges RELA            0000000000000000 0c3dd8 000300 18   I 46  43  8

Best regards,
Jan


[-- Attachment #2: 0001-samples-rust-Add-jump_label-sample-demonstrating-sta.patch --]
[-- Type: text/plain, Size: 7163 bytes --]

From 9703d2ff46c03ec8c006a9302c790c4103510718 Mon Sep 17 00:00:00 2001
From: Jan Polensky <japo@linux.ibm.com>
Date: Wed, 27 May 2026 21:28:26 +0200
Subject: [PATCH 1/1] samples/rust: Add jump_label sample demonstrating static
 branches on s390

This sample demonstrates the use of static branches (jump labels) in Rust
kernel modules on s390 architecture. It successfully generates __jump_table
entries and uses s390-specific jgnop instructions for runtime code patching.

Key components:
- C helper defining DEFINE_STATIC_KEY_FALSE(rust_sample_key)
- Rust module using kernel::jump_label::arch_static_branch! macro
- Composite module build (C + Rust) with proper symbol binding
- Generates real __jump_table section with relocations
- Uses s390 jgnop instruction (6-byte NOP) for branch patching

Verification shows:
- __jump_table section present in compiled module
- Three relocations: code location, target, and key pointer
- s390 jgnop instruction at offset 0x102

The module tests the static branch in a loop, demonstrating that Rust
can leverage the kernel's jump label infrastructure for optimized
conditional branches that can be patched at runtime.

Signed-off-by: Jan Polensky <polensky@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 rust/bindings/bindings_helper.h       |  5 ++
 samples/rust/Kconfig                  | 15 +++++
 samples/rust/Makefile                 |  4 +-
 samples/rust/rust_jump_label_core.rs  | 79 +++++++++++++++++++++++++++
 samples/rust/rust_jump_label_helper.c | 20 +++++++
 5 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100644 samples/rust/rust_jump_label_core.rs
 create mode 100644 samples/rust/rust_jump_label_helper.c

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 446dbeaf0866..539c8d18a72c 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -164,3 +164,8 @@ const unsigned long RUST_CONST_HELPER_GPU_BUDDY_TRIM_DISABLE = GPU_BUDDY_TRIM_DI
 #include "../../drivers/android/binder/rust_binder.h"
 #include "../../drivers/android/binder/rust_binder_events.h"
 #endif
+
+/* Rust jump label sample - external static key */
+#if IS_ENABLED(CONFIG_SAMPLE_RUST_JUMP_LABEL)
+extern struct static_key_false rust_sample_key;
+#endif
diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
index 10364db13872..8c579d861988 100644
--- a/samples/rust/Kconfig
+++ b/samples/rust/Kconfig
@@ -203,4 +203,19 @@ config SAMPLE_RUST_TRIGGER
 
 	  If unsure, say N.
 
+config SAMPLE_RUST_JUMP_LABEL
+	tristate "Jump label (static branch)"
+	depends on JUMP_LABEL
+	help
+	  This option builds the Rust jump label sample module.
+
+	  It demonstrates the use of static branches (jump labels) in Rust
+	  kernel modules, particularly testing ARCH_STATIC_BRANCH_ASM
+	  implementation on s390 architecture.
+
+	  To compile this as a module, choose M here:
+	  the module will be called rust_jump_label.
+
+	  If unsure, say N.
+
 endif # SAMPLES_RUST
diff --git a/samples/rust/Makefile b/samples/rust/Makefile
index 037fd43f9878..f91d8a29802a 100644
--- a/samples/rust/Makefile
+++ b/samples/rust/Makefile
@@ -18,8 +18,10 @@ obj-$(CONFIG_SAMPLE_RUST_CONFIGFS)		+= rust_configfs.o
 obj-$(CONFIG_SAMPLE_RUST_SOC)			+= rust_soc.o
 obj-$(CONFIG_SAMPLE_RUST_BUG)			+= rust_bug.o
 obj-$(CONFIG_SAMPLE_RUST_TRIGGER)		+= rust_trigger.o
+obj-$(CONFIG_SAMPLE_RUST_JUMP_LABEL)		+= rust_jump_label.o
 
 rust_print-y := rust_print_main.o rust_print_events.o
 rust_trigger-y := rust_trigger_main.o rust_print_events.o
+rust_jump_label-y := rust_jump_label_helper.o rust_jump_label_core.o
 
-subdir-$(CONFIG_SAMPLE_RUST_HOSTPROGS)		+= hostprogs
+subdir-$(CONFIG_SAMPLE_RUST_HOSTPROGS)		+= hostprogs
\ No newline at end of file
diff --git a/samples/rust/rust_jump_label_core.rs b/samples/rust/rust_jump_label_core.rs
new file mode 100644
index 000000000000..af3efeb3c2a3
--- /dev/null
+++ b/samples/rust/rust_jump_label_core.rs
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust jump label sample.
+//!
+//! Demonstrates static branches (jump labels) using a C-defined static_key.
+//! Generates __jump_table entries and architecture-specific branch instructions.
+
+use kernel::prelude::*;
+use kernel::sync::atomic::{Atomic, Relaxed};
+
+module! {
+    type: RustJumpLabel,
+    name: "rust_jump_label",
+    authors: ["Jan Polensky"],
+    description: "Rust jump label sample",
+    license: "GPL",
+}
+
+struct RustJumpLabel;
+
+impl kernel::Module for RustJumpLabel {
+    fn init(_module: &'static ThisModule) -> Result<Self> {
+        pr_info!("Rust jump label sample (init)\n");
+
+        let counter = Atomic::new(0);
+        Self::test_jump_label(&counter)?;
+
+        Ok(RustJumpLabel)
+    }
+}
+
+impl RustJumpLabel {
+    fn test_jump_label(counter: &Atomic<u64>) -> Result {
+        for i in 0..10 {
+            counter.fetch_add(1, Relaxed);
+
+            // SAFETY: rust_sample_key is defined in C helper and exported.
+            let branch_taken = unsafe {
+                #[cfg(not(CONFIG_JUMP_LABEL))]
+                {
+                    let key_ptr: *const kernel::bindings::static_key_false =
+                        core::ptr::addr_of!(kernel::bindings::rust_sample_key);
+                    let static_key_ptr: *const kernel::bindings::static_key =
+                        core::ptr::addr_of!((*key_ptr).key);
+                    kernel::bindings::static_key_count(static_key_ptr.cast_mut()) > 0
+                }
+
+                #[cfg(CONFIG_JUMP_LABEL)]
+                {
+                    kernel::jump_label::arch_static_branch!(
+                        kernel::bindings::rust_sample_key,
+                        kernel::bindings::static_key_false,
+                        key,
+                        false
+                    )
+                }
+            };
+
+            if branch_taken {
+                pr_info!("Branch taken at iteration {}\n", i);
+            }
+        }
+
+        let final_count = counter.load(Relaxed);
+        if final_count != 10 {
+            pr_err!("Counter mismatch! Expected 10, got {}\n", final_count);
+            return Err(EINVAL);
+        }
+
+        pr_info!("Test completed. Counter: {}\n", final_count);
+        Ok(())
+    }
+}
+
+impl Drop for RustJumpLabel {
+    fn drop(&mut self) {
+        pr_info!("Rust jump label sample (exit)\n");
+    }
+}
diff --git a/samples/rust/rust_jump_label_helper.c b/samples/rust/rust_jump_label_helper.c
new file mode 100644
index 000000000000..a8e6ebb48846
--- /dev/null
+++ b/samples/rust/rust_jump_label_helper.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * C helper for Rust jump label sample.
+ * Provides a static key that can be used from Rust code.
+ */
+
+#include <linux/module.h>
+#include <linux/jump_label.h>
+
+/*
+ * Define a static key for the Rust module.
+ * This creates the necessary C infrastructure for jump labels.
+ */
+DEFINE_STATIC_KEY_FALSE(rust_sample_key);
+EXPORT_SYMBOL_GPL(rust_sample_key);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("C helper for Rust jump label sample");
+MODULE_AUTHOR("Jan Polensky");
-- 
2.51.0

Re: [PATCH v3 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Gary Guo]

On Thu May 21, 2026 at 5:56 PM BST, Jan Polensky wrote:
> Rust static branch support needs the s390 jump label instruction sequence
> and __jump_table emission in a reusable form. The current implementation
> embeds the sequence directly in the C asm goto blocks, which cannot be
> shared with Rust.
> 
> Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
> describe the brcl sequences for the likely-false and likely-true cases
> and to emit the same __jump_table entries as before. Switch the existing
> C helpers to use the new macros to avoid duplication without changing
> the generated code.
> 
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>

Acked-by: Gary Guo <gary@garyguo.net>

> ---
>  arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
>  1 file changed, 19 insertions(+), 14 deletions(-)

[PATCH v3 3/4] rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts

[Jan Polensky]

Bindgen attempts to generate Rust layouts for a number of s390 structs
that are packed but contain, or transitively contain, aligned fields.
Rust rejects such layouts with E0588 ("packed type cannot transitively
contain a #[repr(align)] type").

Add the affected s390 types to the opaque type list so bindgen emits
opaque blob types instead of full representations. This matches existing
workarounds for x86 types such as alt_instr and x86_msi_data.

References: https://lore.kernel.org/all/e5c7aa10-590d-0d20-dd3b-385bee2377e7@intel.com/
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 rust/bindgen_parameters | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index 6f02d9720ad2..8402b0c93545 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -14,6 +14,13 @@
 --opaque-type alt_instr
 --opaque-type x86_msi_data
 --opaque-type x86_msi_addr_lo
+# s390-only: same packed/align issue as above (E0588).
+--opaque-type lowcore
+--opaque-type tod_clock
+--opaque-type tpi_info
+--opaque-type uv_cb.*
+--opaque-type uv_secret.*
+--opaque-type zpci_fib
 
 # If SMP is disabled, `arch_spinlock_t` is defined as a ZST which triggers a Rust
 # warning. We don't need to peek into it anyway.
-- 
2.51.0

[PATCH v3 4/4] s390: Enable Rust support

[Jan Polensky]

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.

Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 Documentation/rust/arch-support.rst |  1 +
 arch/s390/Kconfig                   |  1 +
 arch/s390/Makefile                  | 28 +++++++++++++++++-----------
 rust/Makefile                       |  1 +
 scripts/generate_rust_target.rs     |  2 ++
 scripts/min-tool-version.sh         |  6 +++++-
 6 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 6e6a515d0899..ce9804b8226c 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -19,6 +19,7 @@ Architecture   Level of support  Constraints
 ``arm64``      Maintained        Little Endian only.
 ``loongarch``  Maintained        \-
 ``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
+``s390``       Maintained        \-
 ``um``         Maintained        \-
 ``x86``        Maintained        ``x86_64`` only.
 =============  ================  ==============================================
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index ecbcbb781e40..26951781d74d 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -248,6 +248,7 @@ config S390
 	select HAVE_RELIABLE_STACKTRACE
 	select HAVE_RETHOOK
 	select HAVE_RSEQ
+	select HAVE_RUST if !EXPOLINE
 	select HAVE_SAMPLE_FTRACE_DIRECT
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
 	select HAVE_SETUP_PER_CPU_AREA
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index 297976b41088..8b712cd85fcd 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -35,25 +35,31 @@ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
 KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
 KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
 
+KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain
+
 UTS_MACHINE	:= s390x
 STACK_SIZE	:= $(if $(CONFIG_KASAN),65536,$(if $(CONFIG_KMSAN),65536,16384))
 CHECKFLAGS	+= -D__s390__ -D__s390x__
 
 export LD_BFD
 
-mflags-$(CONFIG_MARCH_Z10)    := -march=z10
-mflags-$(CONFIG_MARCH_Z196)   := -march=z196
-mflags-$(CONFIG_MARCH_ZEC12)  := -march=zEC12
-mflags-$(CONFIG_MARCH_Z13)    := -march=z13
-mflags-$(CONFIG_MARCH_Z14)    := -march=z14
-mflags-$(CONFIG_MARCH_Z15)    := -march=z15
-mflags-$(CONFIG_MARCH_Z16)    := -march=z16
-mflags-$(CONFIG_MARCH_Z17)    := -march=z17
+march-name-$(CONFIG_MARCH_Z10)   := z10
+march-name-$(CONFIG_MARCH_Z196)  := z196
+march-name-$(CONFIG_MARCH_ZEC12) := zEC12
+march-name-$(CONFIG_MARCH_Z13)   := z13
+march-name-$(CONFIG_MARCH_Z14)   := z14
+march-name-$(CONFIG_MARCH_Z15)   := z15
+march-name-$(CONFIG_MARCH_Z16)   := z16
+march-name-$(CONFIG_MARCH_Z17)   := z17
 
-export CC_FLAGS_MARCH := $(mflags-y)
+mflags := -march=$(march-name-y)
 
-aflags-y += $(mflags-y)
-cflags-y += $(mflags-y)
+export CC_FLAGS_MARCH := $(mflags)
+
+aflags-y += $(mflags)
+cflags-y += $(mflags)
+
+KBUILD_RUSTFLAGS += -Ctarget-cpu=$(march-name-y)
 
 cflags-$(CONFIG_MARCH_Z10_TUNE)		+= -mtune=z10
 cflags-$(CONFIG_MARCH_Z196_TUNE)	+= -mtune=z196
diff --git a/rust/Makefile b/rust/Makefile
index b9e9f512cec3..77460502f576 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -403,6 +403,7 @@ BINDGEN_TARGET_x86	:= x86_64-linux-gnu
 BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
 BINDGEN_TARGET_arm	:= arm-linux-gnueabi
 BINDGEN_TARGET_loongarch	:= loongarch64-linux-gnusf
+BINDGEN_TARGET_s390	:= s390x-linux-gnu
 # This is only for i386 UM builds, which need the 32-bit target not -m32
 BINDGEN_TARGET_i386	:= i386-linux-gnu
 BINDGEN_TARGET_um	:= $(BINDGEN_TARGET_$(SUBARCH))
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..8f1df6819d0b 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -256,6 +256,8 @@ fn main() {
         }
     } else if cfg.has("LOONGARCH") {
         panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
+    } else if cfg.has("S390") {
+        panic!("s390 uses the builtin rustc s390x-unknown-none-softfloat target");
     } else {
         panic!("Unsupported architecture");
     }
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index b96ec2d379b6..296acf8f71aa 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -31,7 +31,11 @@ llvm)
 	fi
 	;;
 rustc)
-	echo 1.85.0
+	if [ "$SRCARCH" = "s390" ]; then
+		echo 1.96.0
+	else
+		echo 1.85.0
+	fi
 	;;
 bindgen)
 	echo 0.71.1
-- 
2.51.0

Re: [PATCH v3 4/4] s390: Enable Rust support

[Alice Ryhl]

On Thu, May 21, 2026 at 06:56:22PM +0200, Jan Polensky wrote:
> 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.
> 
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>

> diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> index b96ec2d379b6..296acf8f71aa 100755
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -31,7 +31,11 @@ llvm)
>  	fi
>  	;;
>  rustc)
> -	echo 1.85.0
> +	if [ "$SRCARCH" = "s390" ]; then
> +		echo 1.96.0
> +	else
> +		echo 1.85.0
> +	fi

For other version constraints we have listed them in the Kconfig file to
guard the select HAVE_RUST or similar annotations instead of here. Is
this the best place to add this constraint?

Alice

Re: [PATCH v3 4/4] s390: Enable Rust support

[Heiko Carstens]

On Wed, May 27, 2026 at 05:59:43AM +0000, Alice Ryhl wrote:
> On Thu, May 21, 2026 at 06:56:22PM +0200, Jan Polensky wrote:
> > 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.
> > 
> > Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> 
> > diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> > index b96ec2d379b6..296acf8f71aa 100755
> > --- a/scripts/min-tool-version.sh
> > +++ b/scripts/min-tool-version.sh
> > @@ -31,7 +31,11 @@ llvm)
> >  	fi
> >  	;;
> >  rustc)
> > -	echo 1.85.0
> > +	if [ "$SRCARCH" = "s390" ]; then
> > +		echo 1.96.0
> > +	else
> > +		echo 1.85.0
> > +	fi
> 
> For other version constraints we have listed them in the Kconfig file to
> guard the select HAVE_RUST or similar annotations instead of here. Is
> this the best place to add this constraint?

This is supposed to be the default location for such constraints.

See also the current limitiations for gcc and llvm in the same file, or the
previous limitations of llvm for x86 and s390, which have been removed with
commit 20c098928356 ("kbuild: Bump minimum version of LLVM for building the
kernel to 15.0.0").

Re: [PATCH v3 4/4] s390: Enable Rust support

[Miguel Ojeda]

On Wed, May 27, 2026 at 8:53 AM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> On Wed, May 27, 2026 at 05:59:43AM +0000, Alice Ryhl wrote:
> >
> > For other version constraints we have listed them in the Kconfig file to
> > guard the select HAVE_RUST or similar annotations instead of here. Is
> > this the best place to add this constraint?
>
> This is supposed to be the default location for such constraints.
>
> See also the current limitiations for gcc and llvm in the same file, or the
> previous limitations of llvm for x86 and s390, which have been removed with
> commit 20c098928356 ("kbuild: Bump minimum version of LLVM for building the
> kernel to 15.0.0").

Yeah, if it can be done in that file (i.e. if it doesn't require the
kernel configuration otherwise), then it is best to keep it there.

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Miguel Ojeda]

On Thu, May 21, 2026 at 7:03 PM Jan Polensky <japo@linux.ibm.com> wrote:
>
> s390 currently requires a rustc due to -Zpacked-stack, and the
> minimum tool version gating is adjusted accordingly.

This doesn't matter unless the maintainer applying this uses a merge
commit for the cover letter, but there is a missing word, and if the
word was meant to be "nightly", then the paragraph is likely outdated
anyway :)

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Heiko Carstens]

Hi Miguel,

On Tue, May 26, 2026 at 03:55:49PM +0200, Miguel Ojeda wrote:
> On Thu, May 21, 2026 at 7:03 PM Jan Polensky <japo@linux.ibm.com> wrote:
> >
> > s390 currently requires a rustc due to -Zpacked-stack, and the
> > minimum tool version gating is adjusted accordingly.
> 
> This doesn't matter unless the maintainer applying this uses a merge
> commit for the cover letter, but there is a missing word, and if the
> word was meant to be "nightly", then the paragraph is likely outdated
> anyway :)

An Ack from you would be appreciated, even though you made it already
clear that this series looks ok.

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Miguel Ojeda]

On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> An Ack from you would be appreciated, even though you made it already
> clear that this series looks ok.

I did a quick `LLVM=1` test and booted it in QEMU. That worked and I
could see the KUnit tests, though we get the:

  warning: unstable feature specified for `-Ctarget-feature`: `backchain`

But I assume you are OK with that for now (and if you are, then
avoiding a custom target is worth it, I would say).

I also found a couple bits: in a KASAN build, I got [1] -- Cc'ing
Boqun in case he is interested:

  [    5.323670] ok 5 rust_allocator
  [    5.324134]     KTAP version 1
  [    5.324194]     # Subtest: rust_atomics
  [    5.324251]     # speed: normal
  [    5.324367]     1..8
  [    5.332184]     # atomic_basic_tests.speed: normal
  [    5.332356]     ok 1 atomic_basic_tests
  [    5.340797]     # atomic_acquire_release_tests.speed: normal
  [    5.341054]     ok 2 atomic_acquire_release_tests
  [    5.344127]
==================================================================
  [    5.344584] BUG: KASAN: stack-out-of-bounds in
rust_helper_atomic_i8_xchg+0xb2/0xc0
  [    5.345283] Read of size 4 at addr 001bff7ffdbefcf0 by task
kunit_try_catch/142
  [    5.345493]
  [    5.346499] CPU: 2 UID: 0 PID: 142 Comm: kunit_try_catch Tainted:
G                 N  7.1.0-rc4-00009-g60c6b4b89923 #10 PREEMPTLAZY
  [    5.347065] Tainted: [N]=TEST
  [    5.347124] Hardware name: QEMU 8561 QEMU (KVM/Linux)
  [    5.347323] Call Trace:
  [    5.347408]  [<001bfffffcb9c6b0>] dump_stack_lvl+0x80/0xa0
  [    5.347663]  [<001bfffffcb90846>] print_report+0xd6/0x310
  [    5.347784]  [<001bfffffd596e08>] kasan_report+0xe8/0x110
  [    5.347895]  [<001bfffffde5a042>] rust_helper_atomic_i8_xchg+0xb2/0xc0
  [    5.347983]  [<001bfffffde917fe>]
_RNvNtNtNtNtCseBLeUu9QniM_6kernel4sync6atomic9predefine5tests36kunit_rust_wrapper_atomic_xchg_tests+0x5be/0x4f90
  [    5.348088]  [<001bfffffdf59e50>] kunit_try_run_case+0x150/0x3d0
  [    5.348194]  [<001bfffffdf60500>]
kunit_generic_run_threadfn_adapter+0x90/0x130
  [    5.348257]  [<001bfffffccf9fde>] kthread+0x33e/0x410
  [    5.348309]  [<001bfffffcba122e>] __ret_from_fork+0x9e/0x3c0
  [    5.348357]  [<001bfffffec96faa>] ret_from_fork+0xa/0x30
  [    5.348531]
  [    5.349184]
  [    5.349261] The buggy address belongs to a vmalloc virtual mapping
  [    5.349620] The buggy address belongs to the physical page:
  [    5.350145] page: refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x791f
  [    5.350563] flags: 0x1ffff00000000000(node=0|zone=0|lastcpupid=0x1ffff)
  [    5.351563] raw: 1ffff00000000000 0000000000000000
001b913b001e47c8 0000000000000000
  [    5.351694] raw: 0000000000000000 0000000000000000
ffffffff00000001 0000000000000000
  [    5.351808] page dumped because: kasan: bad access detected
  [    5.351912]
  [    5.351989] Memory state around the buggy address:
  [    5.352240]  001bff7ffdbefb80: f2 f2 f8 f8 f8 f8 f8 f8 f2 f2 f2
f2 f8 f2 f2 f2
  [    5.352338]  001bff7ffdbefc00: f8 f2 f2 f2 f8 f8 f2 f2 f8 f2 f2
f2 f8 f8 f8 f8
  [    5.352428] >001bff7ffdbefc80: f8 f8 f2 f2 f2 f2 f8 f2 f2 f2 f8
f2 f2 f2 01 f3
  [    5.352553]                                                              ^
  [    5.352762]  001bff7ffdbefd00: 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
  [    5.352862]  001bff7ffdbefd80: 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
  [    5.352976]
==================================================================

I also tried a GCC one without KASAN/KUnit, and got:

  error[E0425]: cannot find function `memchr` in crate `bindings`
       --> rust/kernel/str.rs:857:38
        |
    857 |         let ptr = unsafe {
bindings::memchr(buf.as_ptr().cast(), 0, f.bytes_written() - 1) };
        |                                      ^^^^^^
        |
       ::: rust/bindings/bindings_generated.rs:20572:5
        |
  20572 |     pub fn memcmp(s1: *const ffi::c_void, s2: *const
ffi::c_void, n: usize) -> ffi::c_int;
        |     --------------------------------------------------------------------------------------
similarly named function `memcmp` defined here
        |

So we likely want a Rust helper here in `rust/helpers/`.

Up to you which configs you want to support initially and how clean
you want everything to be, of course, so:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

I hope this helps!

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Alice Ryhl]

On Wed, May 27, 2026 at 12:08:38PM +0200, Miguel Ojeda wrote:
> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >
> > An Ack from you would be appreciated, even though you made it already
> > clear that this series looks ok.
> 
> I did a quick `LLVM=1` test and booted it in QEMU. That worked and I
> could see the KUnit tests, though we get the:
> 
>   warning: unstable feature specified for `-Ctarget-feature`: `backchain`
> 
> But I assume you are OK with that for now (and if you are, then
> avoiding a custom target is worth it, I would say).

Based on some very quick research, it looks like enabling the backchain
target feature does not affect the ABI in the sense that mixing together
object files with and without this option will still work. If that's the
case, we can add this to the list of known target features for this
target in rustc, which will silence this warning.

(If it affects the ABI in a breaking manner, it needs to be added as a
separate flag rather than being added as part of the -Ctarget-feature
flag.)

Alice

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Miguel Ojeda]

On Wed, May 27, 2026 at 12:38 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Based on some very quick research, it looks like enabling the backchain
> target feature does not affect the ABI in the sense that mixing together
> object files with and without this option will still work. If that's the
> case, we can add this to the list of known target features for this
> target in rustc, which will silence this warning.
>
> (If it affects the ABI in a breaking manner, it needs to be added as a
> separate flag rather than being added as part of the -Ctarget-feature
> flag.)

Yes, from the different discussions what I saw is that the issue was
mixing it with `-Zpacked-struct`, but that is already rejected by the
compiler. They also discussed whether it should have been its own
flag, though.

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Heiko Carstens]

On Wed, May 27, 2026 at 02:10:25PM +0200, Miguel Ojeda wrote:
> On Wed, May 27, 2026 at 12:38 PM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > Based on some very quick research, it looks like enabling the backchain
> > target feature does not affect the ABI in the sense that mixing together
> > object files with and without this option will still work. If that's the
> > case, we can add this to the list of known target features for this
> > target in rustc, which will silence this warning.
> >
> > (If it affects the ABI in a breaking manner, it needs to be added as a
> > separate flag rather than being added as part of the -Ctarget-feature
> > flag.)
> 
> Yes, from the different discussions what I saw is that the issue was
> mixing it with `-Zpacked-struct`, but that is already rejected by the
> compiler. They also discussed whether it should have been its own
> flag, though.

I guess you meant `-Zpacked-stack`? We need both `-Zpacked-stack`, as
well as `-Ctarget-feature=+backchain`. Otherwise the result would be
incorrect code, due to different stack layouts.

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Miguel Ojeda]

On Wed, May 27, 2026 at 3:44 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> I guess you meant `-Zpacked-stack`? We need both `-Zpacked-stack`, as
> well as `-Ctarget-feature=+backchain`. Otherwise the result would be
> incorrect code, due to different stack layouts.

Yeah, I was referring to the case when the softfloat target is not
used, i.e. I was replying to Alice in general terms for upstream Rust.
The combination in the patch here is accepted.

By the way, the compiler diagnostic added by Eddy (a colleague of
yours, I assume) that mentions it is nice:

  error: `-Zpacked-stack` is incompatible with `backchain` target feature
    |
    = note: enabling both `-Zpacked-stack` and the `backchain` target
feature is incompatible with the default s390x ABI. Switch to
s390x-unknown-none-softfloat if you need both attributes

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Gary Guo]

On Wed May 27, 2026 at 11:08 AM BST, Miguel Ojeda wrote:
> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>>
>> An Ack from you would be appreciated, even though you made it already
>> clear that this series looks ok.
>
> I did a quick `LLVM=1` test and booted it in QEMU. That worked and I
> could see the KUnit tests, though we get the:
>
>   warning: unstable feature specified for `-Ctarget-feature`: `backchain`
>
> But I assume you are OK with that for now (and if you are, then
> avoiding a custom target is worth it, I would say).
>
> I also found a couple bits: in a KASAN build, I got [1] -- Cc'ing
> Boqun in case he is interested:
>
>   [    5.323670] ok 5 rust_allocator
>   [    5.324134]     KTAP version 1
>   [    5.324194]     # Subtest: rust_atomics
>   [    5.324251]     # speed: normal
>   [    5.324367]     1..8
>   [    5.332184]     # atomic_basic_tests.speed: normal
>   [    5.332356]     ok 1 atomic_basic_tests
>   [    5.340797]     # atomic_acquire_release_tests.speed: normal
>   [    5.341054]     ok 2 atomic_acquire_release_tests
>   [    5.344127]
> ==================================================================
>   [    5.344584] BUG: KASAN: stack-out-of-bounds in
> rust_helper_atomic_i8_xchg+0xb2/0xc0
>   [    5.345283] Read of size 4 at addr 001bff7ffdbefcf0 by task
> kunit_try_catch/142
>   [    5.345493]
>   [    5.346499] CPU: 2 UID: 0 PID: 142 Comm: kunit_try_catch Tainted:
> G                 N  7.1.0-rc4-00009-g60c6b4b89923 #10 PREEMPTLAZY
>   [    5.347065] Tainted: [N]=TEST
>   [    5.347124] Hardware name: QEMU 8561 QEMU (KVM/Linux)
>   [    5.347323] Call Trace:
>   [    5.347408]  [<001bfffffcb9c6b0>] dump_stack_lvl+0x80/0xa0
>   [    5.347663]  [<001bfffffcb90846>] print_report+0xd6/0x310
>   [    5.347784]  [<001bfffffd596e08>] kasan_report+0xe8/0x110
>   [    5.347895]  [<001bfffffde5a042>] rust_helper_atomic_i8_xchg+0xb2/0xc0
>   [    5.347983]  [<001bfffffde917fe>]
> _RNvNtNtNtNtCseBLeUu9QniM_6kernel4sync6atomic9predefine5tests36kunit_rust_wrapper_atomic_xchg_tests+0x5be/0x4f90
>   [    5.348088]  [<001bfffffdf59e50>] kunit_try_run_case+0x150/0x3d0
>   [    5.348194]  [<001bfffffdf60500>]
> kunit_generic_run_threadfn_adapter+0x90/0x130
>   [    5.348257]  [<001bfffffccf9fde>] kthread+0x33e/0x410
>   [    5.348309]  [<001bfffffcba122e>] __ret_from_fork+0x9e/0x3c0
>   [    5.348357]  [<001bfffffec96faa>] ret_from_fork+0xa/0x30

Looking at the functions and the test case I don't understand how this could
happen. Could be a miscompilation?

Perhaps it'll be useful to provide rustc and Clang/LLVM versions so it can be
investigated.

>   [    5.348531]
>   [    5.349184]
>   [    5.349261] The buggy address belongs to a vmalloc virtual mapping
>   [    5.349620] The buggy address belongs to the physical page:
>   [    5.350145] page: refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x791f
>   [    5.350563] flags: 0x1ffff00000000000(node=0|zone=0|lastcpupid=0x1ffff)
>   [    5.351563] raw: 1ffff00000000000 0000000000000000
> 001b913b001e47c8 0000000000000000
>   [    5.351694] raw: 0000000000000000 0000000000000000
> ffffffff00000001 0000000000000000
>   [    5.351808] page dumped because: kasan: bad access detected
>   [    5.351912]
>   [    5.351989] Memory state around the buggy address:
>   [    5.352240]  001bff7ffdbefb80: f2 f2 f8 f8 f8 f8 f8 f8 f2 f2 f2
> f2 f8 f2 f2 f2
>   [    5.352338]  001bff7ffdbefc00: f8 f2 f2 f2 f8 f8 f2 f2 f8 f2 f2
> f2 f8 f8 f8 f8
>   [    5.352428] >001bff7ffdbefc80: f8 f8 f2 f2 f2 f2 f8 f2 f2 f2 f8
> f2 f2 f2 01 f3
>   [    5.352553]                                                              ^
>   [    5.352762]  001bff7ffdbefd00: 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00
>   [    5.352862]  001bff7ffdbefd80: 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00
>   [    5.352976]
> ==================================================================
>
> I also tried a GCC one without KASAN/KUnit, and got:
>
>   error[E0425]: cannot find function `memchr` in crate `bindings`
>        --> rust/kernel/str.rs:857:38
>         |
>     857 |         let ptr = unsafe {
> bindings::memchr(buf.as_ptr().cast(), 0, f.bytes_written() - 1) };
>         |                                      ^^^^^^
>         |
>        ::: rust/bindings/bindings_generated.rs:20572:5
>         |
>   20572 |     pub fn memcmp(s1: *const ffi::c_void, s2: *const
> ffi::c_void, n: usize) -> ffi::c_int;
>         |     --------------------------------------------------------------------------------------
> similarly named function `memcmp` defined here
>         |
>
> So we likely want a Rust helper here in `rust/helpers/`.

#if !defined(CONFIG_KASAN) && !defined(CONFIG_KMSAN)
#define __HAVE_ARCH_MEMCHR	/* inline & arch function */

So it looks like you're either going to hit the sanitizer, or the build error :)

Best,
Gary

>
> Up to you which configs you want to support initially and how clean
> you want everything to be, of course, so:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>
> I hope this helps!
>
> Cheers,
> Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Miguel Ojeda]

On Wed, May 27, 2026 at 12:53 PM Gary Guo <gary@garyguo.net> wrote:
>
> Looking at the functions and the test case I don't understand how this could
> happen. Could be a miscompilation?
>
> Perhaps it'll be useful to provide rustc and Clang/LLVM versions so it can be
> investigated.

Yeah, as we discussed, it seems due to s390 emulating 1-byte `xchg`
with a 4-byte read.

A deterministic reproducer is e.g.:

  make LLVM=1 ARCH=s390 defconfig + KASAN + no MODVERSIONS + RUST + KUNIT

  qemu-system-s390x -kernel arch/s390/boot/bzImage -nographic -m 1G

Cheers,
Miguel

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Gary Guo]

On Wed May 27, 2026 at 11:08 AM BST, Miguel Ojeda wrote:
> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>>
>> An Ack from you would be appreciated, even though you made it already
>> clear that this series looks ok.
>
> I did a quick `LLVM=1` test and booted it in QEMU. That worked and I
> could see the KUnit tests, though we get the:
>
>   warning: unstable feature specified for `-Ctarget-feature`: `backchain`
>
> But I assume you are OK with that for now (and if you are, then
> avoiding a custom target is worth it, I would say).
>
> I also found a couple bits: in a KASAN build, I got [1] -- Cc'ing
> Boqun in case he is interested:
>
>   [    5.323670] ok 5 rust_allocator
>   [    5.324134]     KTAP version 1
>   [    5.324194]     # Subtest: rust_atomics
>   [    5.324251]     # speed: normal
>   [    5.324367]     1..8
>   [    5.332184]     # atomic_basic_tests.speed: normal
>   [    5.332356]     ok 1 atomic_basic_tests
>   [    5.340797]     # atomic_acquire_release_tests.speed: normal
>   [    5.341054]     ok 2 atomic_acquire_release_tests
>   [    5.344127]
> ==================================================================
>   [    5.344584] BUG: KASAN: stack-out-of-bounds in
> rust_helper_atomic_i8_xchg+0xb2/0xc0
>   [    5.345283] Read of size 4 at addr 001bff7ffdbefcf0 by task
> kunit_try_catch/142
>   [    5.345493]
>   [    5.346499] CPU: 2 UID: 0 PID: 142 Comm: kunit_try_catch Tainted:
> G                 N  7.1.0-rc4-00009-g60c6b4b89923 #10 PREEMPTLAZY
>   [    5.347065] Tainted: [N]=TEST
>   [    5.347124] Hardware name: QEMU 8561 QEMU (KVM/Linux)
>   [    5.347323] Call Trace:
>   [    5.347408]  [<001bfffffcb9c6b0>] dump_stack_lvl+0x80/0xa0
>   [    5.347663]  [<001bfffffcb90846>] print_report+0xd6/0x310
>   [    5.347784]  [<001bfffffd596e08>] kasan_report+0xe8/0x110
>   [    5.347895]  [<001bfffffde5a042>] rust_helper_atomic_i8_xchg+0xb2/0xc0
>   [    5.347983]  [<001bfffffde917fe>]
> _RNvNtNtNtNtCseBLeUu9QniM_6kernel4sync6atomic9predefine5tests36kunit_rust_wrapper_atomic_xchg_tests+0x5be/0x4f90
>   [    5.348088]  [<001bfffffdf59e50>] kunit_try_run_case+0x150/0x3d0
>   [    5.348194]  [<001bfffffdf60500>]
> kunit_generic_run_threadfn_adapter+0x90/0x130
>   [    5.348257]  [<001bfffffccf9fde>] kthread+0x33e/0x410
>   [    5.348309]  [<001bfffffcba122e>] __ret_from_fork+0x9e/0x3c0
>   [    5.348357]  [<001bfffffec96faa>] ret_from_fork+0xa/0x30

The issue looks like an incorrect implementation of __arch_xchg1 and
__arch_xchg2 for s390. The `READ_ONCE` (and subsequent cmpxchg) causes a 4-byte
operations when only 1-byte can be touched.

The functions should either be re-implemented in assembly, or be marked as
__no_sanitize_or_inline.

Best,
Gary

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Heiko Carstens]

On Wed, May 27, 2026 at 12:54:13PM +0100, Gary Guo wrote:
> On Wed May 27, 2026 at 11:08 AM BST, Miguel Ojeda wrote:
> > On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> > I also found a couple bits: in a KASAN build, I got [1] -- Cc'ing
> > Boqun in case he is interested:
> >
> >   [    5.323670] ok 5 rust_allocator
> >   [    5.324134]     KTAP version 1
> >   [    5.324194]     # Subtest: rust_atomics
> >   [    5.324251]     # speed: normal
> >   [    5.324367]     1..8
> >   [    5.332184]     # atomic_basic_tests.speed: normal
> >   [    5.332356]     ok 1 atomic_basic_tests
> >   [    5.340797]     # atomic_acquire_release_tests.speed: normal
> >   [    5.341054]     ok 2 atomic_acquire_release_tests
> >   [    5.344127]
> > ==================================================================
> >   [    5.344584] BUG: KASAN: stack-out-of-bounds in
> > rust_helper_atomic_i8_xchg+0xb2/0xc0
> >   [    5.345283] Read of size 4 at addr 001bff7ffdbefcf0 by task
> > kunit_try_catch/142
> >   [    5.345493]
> >   [    5.346499] CPU: 2 UID: 0 PID: 142 Comm: kunit_try_catch Tainted:
> > G                 N  7.1.0-rc4-00009-g60c6b4b89923 #10 PREEMPTLAZY
> >   [    5.347065] Tainted: [N]=TEST
> >   [    5.347124] Hardware name: QEMU 8561 QEMU (KVM/Linux)
> >   [    5.347323] Call Trace:
> >   [    5.347408]  [<001bfffffcb9c6b0>] dump_stack_lvl+0x80/0xa0
> >   [    5.347663]  [<001bfffffcb90846>] print_report+0xd6/0x310
> >   [    5.347784]  [<001bfffffd596e08>] kasan_report+0xe8/0x110
> >   [    5.347895]  [<001bfffffde5a042>] rust_helper_atomic_i8_xchg+0xb2/0xc0
> >   [    5.347983]  [<001bfffffde917fe>]
> > _RNvNtNtNtNtCseBLeUu9QniM_6kernel4sync6atomic9predefine5tests36kunit_rust_wrapper_atomic_xchg_tests+0x5be/0x4f90
> >   [    5.348088]  [<001bfffffdf59e50>] kunit_try_run_case+0x150/0x3d0
> >   [    5.348194]  [<001bfffffdf60500>]
> > kunit_generic_run_threadfn_adapter+0x90/0x130
> >   [    5.348257]  [<001bfffffccf9fde>] kthread+0x33e/0x410
> >   [    5.348309]  [<001bfffffcba122e>] __ret_from_fork+0x9e/0x3c0
> >   [    5.348357]  [<001bfffffec96faa>] ret_from_fork+0xa/0x30
> 
> The issue looks like an incorrect implementation of __arch_xchg1 and
> __arch_xchg2 for s390. The `READ_ONCE` (and subsequent cmpxchg) causes a 4-byte
> operations when only 1-byte can be touched.
> 
> The functions should either be re-implemented in assembly, or be marked as
> __no_sanitize_or_inline.

I wouldn't call the implementation incorrect; due to lack of native 1- and
2-byte cmpxchg instructions those have to be emulated with the 4-byte variant.

So yes, the fix seems to be to mark those variants of __arch_xchg() and
__arch_cmpxchg() __no_sanitize_or_inline. But that's up to Jan :)

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Jan Polensky]

On Wed, May 27, 2026 at 12:08:38PM +0200, Miguel Ojeda wrote:
> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >
> > An Ack from you would be appreciated, even though you made it already
> > clear that this series looks ok.
>
[snip]
> similarly named function `memcmp` defined here
>         |
>
> So we likely want a Rust helper here in `rust/helpers/`.
>
> Up to you which configs you want to support initially and how clean
> you want everything to be, of course, so:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>
> I hope this helps!
>
> Cheers,
> Miguel
Hi Miguel,

thanks a lot for testing and for the Ack.

The backchain warning is known. The KASAN report around the 1/2-byte
xchg emulation and the missing memchr in some configurations look like
separate follow-up patches rather than issues in this series, and I
plan to address them separately.

Best regards,
Jan

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Gary Guo]

On Thu May 28, 2026 at 3:03 PM BST, Jan Polensky wrote:
> On Wed, May 27, 2026 at 12:08:38PM +0200, Miguel Ojeda wrote:
>> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>> >
>> > An Ack from you would be appreciated, even though you made it already
>> > clear that this series looks ok.
>>
> [snip]
>> similarly named function `memcmp` defined here
>>         |
>>
>> So we likely want a Rust helper here in `rust/helpers/`.
>>
>> Up to you which configs you want to support initially and how clean
>> you want everything to be, of course, so:
>>
>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>>
>> I hope this helps!
>>
>> Cheers,
>> Miguel
> Hi Miguel,
>
> thanks a lot for testing and for the Ack.
>
> The backchain warning is known. The KASAN report around the 1/2-byte
> xchg emulation and the missing memchr in some configurations look like
> separate follow-up patches rather than issues in this series, and I
> plan to address them separately.
>
> Best regards,
> Jan

The memchr problem is something that need to be addressed in the series, because
by introducing s390 into a mix you're turning a function that was previously
always externed to something that cna be `static inline` and need helpers.

KASAN fix can go separately.

Best,
Gary

Re: [PATCH v3 0/4] s390: Enable Rust support and add required arch glue

[Jan Polensky]

On Thu, May 28, 2026 at 03:14:29PM +0100, Gary Guo wrote:
> On Thu May 28, 2026 at 3:03 PM BST, Jan Polensky wrote:
> > On Wed, May 27, 2026 at 12:08:38PM +0200, Miguel Ojeda wrote:
> >> On Tue, May 26, 2026 at 6:13 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >> >
> >> > An Ack from you would be appreciated, even though you made it already
> >> > clear that this series looks ok.
> >>
> > [snip]
> >> similarly named function `memcmp` defined here
> >>         |
> >>
> >> So we likely want a Rust helper here in `rust/helpers/`.
> >>
> >> Up to you which configs you want to support initially and how clean
> >> you want everything to be, of course, so:
> >>
> >> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> >>
> >> I hope this helps!
> >>
> >> Cheers,
> >> Miguel
> > Hi Miguel,
> >
> > thanks a lot for testing and for the Ack.
> >
> > The backchain warning is known. The KASAN report around the 1/2-byte
> > xchg emulation and the missing memchr in some configurations look like
> > separate follow-up patches rather than issues in this series, and I
> > plan to address them separately.
> >
> > Best regards,
> > Jan
>
> The memchr problem is something that need to be addressed in the series, because
> by introducing s390 into a mix you're turning a function that was previously
> always externed to something that cna be `static inline` and need helpers.
>
> KASAN fix can go separately.
>
> Best,
> Gary
Hi Gary,

thanks, I'll include the memchr-related changes and some more in v4.

Best regards,
Jan
``