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

[Heiko Carstens <hca@linux.ibm.com>]

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 :)