Re: [PATCH v2 0/4] rust: Add i8/i16 atomic xchg helpers

[Boqun Feng <boqun.feng@gmail.com>]

On Sat, Dec 27, 2025 at 06:17:17PM +0900, FUJITA Tomonori wrote:
> On Sat, 27 Dec 2025 15:23:30 +0800
> Boqun Feng <boqun.feng@gmail.com> wrote:
> 
> > On Thu, Dec 25, 2025 at 09:56:55AM +0900, FUJITA Tomonori wrote:
> > [...]
> >> >> The architectures supporting Rust, implement atomic xchg families
> >> >> using architecture-specific instructions. They work for i8/i16 too so
> >> >> the helpers just call them.
> >> >> 
> >> >> Tested on QEMU (86_64, arm64, riscv, loongarch, and armv7).
> >> >> 
> >> >> Note the architectures that support Rust handle xchg differently:
> >> >> 
> >> >> - arm64 and riscv support xchg with all the orderings.
> >> >> 
> >> >> - x86_64 and loongarch support only full-ordering xchg. They calls the
> >> >>   full-ordering xchg for any orderings.
> >> > 
> >> > Maybe it's just that I'm reading this differently, but I think this is a
> >> > bit confusing, as if there's an optimisation opportunity.
> >> > 
> >> > x86 is TSO, so even a relaxed xchg is a full xchg. So in this sense x86
> >> > has implemented all orderings.
> >> 
> >> For x86_64, I agree that the wording is confusing. xchg always implies
> >> lock so different memory orderings all map to the same full-ordered
> >> xchg there.
> >> 
> > 
> > I feel a bit confusing as well about the need of mentioning the exact
> > ordering of these primitives on each arch. In my opinion, as long as
> > rust_helper_xchg_X() is mapped to xchg_X() in C, then it's clear that
> > they have the ordering of the corresponding C APIs. But I keep it as it
> > is for now, I may remove them from the commit logs later after I
> > re-think about this.
> 
> Given the current implementation, I agree that the ordering
> explanation is redundant.
> 
> When I started working on this, I initially thought we would need
> architecture-specific ifdefs to select the appropriate implementation
> for each ordering, rather than having a straightforward per-ordering
> mapping like this. That's why I added the explanation about how xchg
> is handled on each architecture.
> 

I will remove those ordering explanation and I will also apply other
changes to the xchg/cmpxchg helpers: we should use xchg() and
try_cmpxchg() instead of raw_xchg() and raw_try_cmpxchg() because we
want to keep the KCSan instrumentation for those helpers.

Regards,
Boqun

> 
> > Thank you all! Applied in rust-sync:
> > 
> > 	https://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git/ rust-sync
> 
> Thanks a lot!
>