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

["Gary Guo" <gary@garyguo.net>]

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