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

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

[FUJITA Tomonori]

This adds atomic xchg helpers with full, acquire, release, and relaxed
orderings in preparation for i8/i16 atomic xchg support.

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.

- arm v7 supports only relaxed-odering xchg. It uses __atomic_op_
 macros to add barriers properly.

v2:
- Add comment about ARCH_SUPPORTS_ATOMIC_RMW dependency
- Add Alice's Reviewed-by
v1: https://lore.kernel.org/rust-for-linux/20251217213742.639812-1-fujita.tomonori@gmail.com/

FUJITA Tomonori (4):
  rust: helpers: Add i8/i16 atomic xchg helpers
  rust: helpers: Add i8/i16 atomic xchg_acquire helpers
  rust: helpers: Add i8/i16 atomic xchg_release helpers
  rust: helpers: Add i8/i16 atomic xchg_relaxed helpers

 rust/helpers/atomic_ext.c | 48 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)


base-commit: cae418334e4c402e410d3ee234935da33c7f904b
-- 
2.43.0

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

[FUJITA Tomonori]

Add i8/i16 atomic xchg helpers that call raw_xchg() macro implementing
atomic xchg using architecture-specific instructions.

x86_64, loongarch, arm64, and riscv implement xchg with full ordering.

arm v7 only supports relaxed-ordering xchg; __atomic_op_fence() macro
is used to add barriers before and after the relaxed xchg.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
 rust/helpers/atomic_ext.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/rust/helpers/atomic_ext.c b/rust/helpers/atomic_ext.c
index fedf808383e0..b1ce7c038ac4 100644
--- a/rust/helpers/atomic_ext.c
+++ b/rust/helpers/atomic_ext.c
@@ -2,6 +2,7 @@
 
 #include <asm/barrier.h>
 #include <asm/rwonce.h>
+#include <linux/atomic.h>
 
 __rust_helper s8 rust_helper_atomic_i8_load(s8 *ptr)
 {
@@ -42,3 +43,20 @@ __rust_helper void rust_helper_atomic_i16_store_release(s16 *ptr, s16 val)
 {
 	smp_store_release(ptr, val);
 }
+
+/*
+ * xchg helpers depend on ARCH_SUPPORTS_ATOMIC_RMW and on the
+ * architecture provding xchg() support for i8 and i16.
+ *
+ * The architectures that currently support Rust (x86_64, armv7,
+ * arm64, riscv, and loongarch) satisfy these requirements.
+ */
+__rust_helper s8 rust_helper_atomic_i8_xchg(s8 *ptr, s8 new)
+{
+	return raw_xchg(ptr, new);
+}
+
+__rust_helper s16 rust_helper_atomic_i16_xchg(s16 *ptr, s16 new)
+{
+	return raw_xchg(ptr, new);
+}
-- 
2.43.0

[PATCH v2 2/4] rust: helpers: Add i8/i16 atomic xchg_acquire helpers

[FUJITA Tomonori]

Add i8/i16 atomic xchg_acquire helpers that call raw_xchg_acquire()
macro implementing atomic xchg_acquire using architecture-specific
instructions.

x86_64 and loongarch use full-ordering xchg.

arm64 and riscv implement acquire-ordering xchg.

arm v7 only supports relaxed-ordering xchg; __atomic_op_acquire() macro
is used to add barriers after the relaxed xchg.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
 rust/helpers/atomic_ext.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/rust/helpers/atomic_ext.c b/rust/helpers/atomic_ext.c
index b1ce7c038ac4..538e0b10a15b 100644
--- a/rust/helpers/atomic_ext.c
+++ b/rust/helpers/atomic_ext.c
@@ -60,3 +60,13 @@ __rust_helper s16 rust_helper_atomic_i16_xchg(s16 *ptr, s16 new)
 {
 	return raw_xchg(ptr, new);
 }
+
+__rust_helper s8 rust_helper_atomic_i8_xchg_acquire(s8 *ptr, s8 new)
+{
+	return raw_xchg_acquire(ptr, new);
+}
+
+__rust_helper s16 rust_helper_atomic_i16_xchg_acquire(s16 *ptr, s16 new)
+{
+	return raw_xchg_acquire(ptr, new);
+}
-- 
2.43.0

[PATCH v2 3/4] rust: helpers: Add i8/i16 atomic xchg_release helpers

[FUJITA Tomonori]

Add i8/i16 atomic xchg_release helpers that call raw_xchg_release()
macro implementing atomic xchg_release using architecture-specific
instructions.

x86_64 and loongarch use full-ordering xchg.

arm64 and riscv implement release-ordering xchg.

arm v7 only supports relaxed-ordering xchg; __atomic_op_release()
macro is used to add barriers before the relaxed xchg.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
 rust/helpers/atomic_ext.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/rust/helpers/atomic_ext.c b/rust/helpers/atomic_ext.c
index 538e0b10a15b..a48bb632dc44 100644
--- a/rust/helpers/atomic_ext.c
+++ b/rust/helpers/atomic_ext.c
@@ -70,3 +70,13 @@ __rust_helper s16 rust_helper_atomic_i16_xchg_acquire(s16 *ptr, s16 new)
 {
 	return raw_xchg_acquire(ptr, new);
 }
+
+__rust_helper s8 rust_helper_atomic_i8_xchg_release(s8 *ptr, s8 new)
+{
+	return raw_xchg_release(ptr, new);
+}
+
+__rust_helper s16 rust_helper_atomic_i16_xchg_release(s16 *ptr, s16 new)
+{
+	return raw_xchg_release(ptr, new);
+}
-- 
2.43.0

[PATCH v2 4/4] rust: helpers: Add i8/i16 atomic xchg_relaxed helpers

[FUJITA Tomonori]

Add i8/i16 atomic xchg_relaxed helpers that call raw_xchg_relaxed()
macro implementing atomic xchg_relaxed using architecture-specific
instructions.

x86_64 and loongarch use full-ordering xchg.

arm64, riscv, and arm v7 implement relaxed-ordering xchg.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
 rust/helpers/atomic_ext.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/rust/helpers/atomic_ext.c b/rust/helpers/atomic_ext.c
index a48bb632dc44..089f31bc8de8 100644
--- a/rust/helpers/atomic_ext.c
+++ b/rust/helpers/atomic_ext.c
@@ -80,3 +80,13 @@ __rust_helper s16 rust_helper_atomic_i16_xchg_release(s16 *ptr, s16 new)
 {
 	return raw_xchg_release(ptr, new);
 }
+
+__rust_helper s8 rust_helper_atomic_i8_xchg_relaxed(s8 *ptr, s8 new)
+{
+	return raw_xchg_relaxed(ptr, new);
+}
+
+__rust_helper s16 rust_helper_atomic_i16_xchg_relaxed(s16 *ptr, s16 new)
+{
+	return raw_xchg_relaxed(ptr, new);
+}
-- 
2.43.0

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

[Gary Guo]

On Tue, 23 Dec 2025 15:21:36 +0900
FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:

> This adds atomic xchg helpers with full, acquire, release, and relaxed
> orderings in preparation for i8/i16 atomic xchg support.


Any reason this series is not sent together with the user (i.e.
Rust support) that uses it?

> 
> 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.

Looking at loongarch ISA manual it's suggested that apart from load/store,
all other atomic memory instructions are also always full ordering.

The change themselves LGTM, so

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

Best,
Gary

> 
> - arm v7 supports only relaxed-odering xchg. It uses __atomic_op_
>  macros to add barriers properly.


> 
> v2:
> - Add comment about ARCH_SUPPORTS_ATOMIC_RMW dependency
> - Add Alice's Reviewed-by
> v1: https://lore.kernel.org/rust-for-linux/20251217213742.639812-1-fujita.tomonori@gmail.com/
> 
> FUJITA Tomonori (4):
>   rust: helpers: Add i8/i16 atomic xchg helpers
>   rust: helpers: Add i8/i16 atomic xchg_acquire helpers
>   rust: helpers: Add i8/i16 atomic xchg_release helpers
>   rust: helpers: Add i8/i16 atomic xchg_relaxed helpers
> 
>  rust/helpers/atomic_ext.c | 48 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> 
> base-commit: cae418334e4c402e410d3ee234935da33c7f904b

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

[FUJITA Tomonori]

Hi,

On Tue, 23 Dec 2025 12:46:39 +0000
Gary Guo <gary@garyguo.net> wrote:

> On Tue, 23 Dec 2025 15:21:36 +0900
> FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
> 
>> This adds atomic xchg helpers with full, acquire, release, and relaxed
>> orderings in preparation for i8/i16 atomic xchg support.
> 
> 
> Any reason this series is not sent together with the user (i.e.
> Rust support) that uses it?

The users are generated via macros that add xchg/try_cmpxchg methods
and their tests, so sending everything together would result in more
than ten patches at once.

I wanted to send the bindings first to make it easier to review them
on their own. In this case the API is already clear, so I don't think
it is strictly necessary to include the users in the same series.


>> 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.


> Looking at loongarch ISA manual it's suggested that apart from load/store,
> all other atomic memory instructions are also always full ordering.

On loongarch there are two possible implementations: an LL/SC-based
one, which is effectively always full-ordered (similar to x86), and an
AMO-based on, where weaker orderings may be possible, as only the AM
variants with the DBAR function appear to be full-ordered.


> The change themselves LGTM, so
> 
> Reviewed-by: Gary Guo <gary@garyguo.net>

Thanks a lot!

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

[Boqun Feng]

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.

> 
> > Looking at loongarch ISA manual it's suggested that apart from load/store,
> > all other atomic memory instructions are also always full ordering.
> 
> On loongarch there are two possible implementations: an LL/SC-based
> one, which is effectively always full-ordered (similar to x86), and an
> AMO-based on, where weaker orderings may be possible, as only the AM
> variants with the DBAR function appear to be full-ordered.
> 
> 
> > The change themselves LGTM, so
> > 
> > Reviewed-by: Gary Guo <gary@garyguo.net>
> 
> Thanks a lot!
> 

Thank you all! Applied in rust-sync:

	https://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git/ rust-sync

Regards,
Boqun

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

[FUJITA Tomonori]

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.


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

Thanks a lot!

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

[Boqun Feng]

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!
> 

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

[FUJITA Tomonori]

On Tue, 30 Dec 2025 09:14:19 +0800
Boqun Feng <boqun.feng@gmail.com> wrote:

> 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.

You are right, I should have used those. Thanks for pointing it out.

Please let me know if you'd like me to send updated patches for the
bindings. If you prefer to apply the changes yourself, that works for
me as well.