linux.git/rust/kernel/sync/atomic/internal.rs, branch v7.1-rc2

rust: atomic: Update a safety comment in impl of `fetch_add()`

2026-03-08T10:06:51+00:00

The safety comment used in the implementation of `fetch_add()` could be
read as just saying something it is true without justifying it. Update
the safety comment to include justification.

Suggested-by: Miguel Ojeda 
Signed-off-by: Andreas Hindborg 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260220-atomic-sub-v3-3-e63cbed1d2aa@kernel.org
Link: https://patch.msgid.link/20260303201701.12204-14-boqun@kernel.org

rust: sync: atomic: Add fetch_sub()

2026-03-08T10:06:50+00:00

Add `Atomic::fetch_sub()` with implementation and documentation in line
with existing `Atomic::fetch_add()` implementation.

Signed-off-by: Andreas Hindborg 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260220-atomic-sub-v3-1-e63cbed1d2aa@kernel.org
Link: https://patch.msgid.link/20260303201701.12204-12-boqun@kernel.org

rust: sync: atomic: Add Atomic<*{mut,const} T> support

2026-03-08T10:06:49+00:00

Atomic pointer support is an important piece of synchronization
algorithm, e.g. RCU, hence provide the support for that.

Note that instead of relying on atomic_long or the implementation of
`Atomic`, a new set of helpers (atomic_ptr_*) is introduced for
atomic pointer specifically, this is because ptr2int casting would
lose the provenance of a pointer and even though in theory there are a
few tricks the provenance can be restored, it'll still be a simpler
implementation if C could provide atomic pointers directly. The side
effects of this approach are: we don't have the arithmetic and logical
operations for pointers yet and the current implementation only works
on ARCH_SUPPORTS_ATOMIC_RMW architectures, but these are implementation
issues and can be added later.

Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Gary Guo 
Reviewed-by: FUJITA Tomonori 
Link: https://patch.msgid.link/20260120140503.62804-3-boqun.feng@gmail.com
Link: https://patch.msgid.link/20260303201701.12204-8-boqun@kernel.org

rust: sync: atomic: Clarify the need of CONFIG_ARCH_SUPPORTS_ATOMIC_RMW

2026-03-08T10:06:49+00:00

Currently, since all the architectures that support Rust all have
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW selected, the helpers of atomic
load/store on i8 and i16 relies on CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y.
It's generally fine since most of architectures support that.

The plan for CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=n architectures is adding
their (probably lock-based) atomic load/store for i8 and i16 as their
atomic_{read,set}() and atomic64_{read,set}() counterpart when they
plans to support Rust.

Hence use a statis_assert!() to check this and remind the future us the
need of the helpers. This is more clear than the #[cfg] on impl blocks
of i8 and i16.

Suggested-by: Dirk Behme 
Suggested-by: Benno Lossin 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260120140503.62804-2-boqun.feng@gmail.com
Link: https://patch.msgid.link/20260303201701.12204-7-boqun@kernel.org

rust: sync: atomic: Add i8/i16 xchg and cmpxchg support

2026-01-09T11:01:41+00:00

Add atomic xchg and cmpxchg operation support for i8 and i16 types
with tests.

Note that since the current implementation of
Atomic::<{i8,i16}>::{load,store}() is READ_ONCE()/WRITE_ONCE()-based.
The atomicity between load/store and xchg/cmpxchg is only guaranteed if
the architecture has native RmW support, hence i8/i16 is currently
AtomicImpl only when CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y.

[boqun: Make i8/i16 AtomicImpl only when
CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y]

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Boqun Feng 
Link: https://patch.msgid.link/20251228120546.1602275-4-fujita.tomonori@gmail.com

rust: sync: atomic: Add i8/i16 load and store support

2026-01-09T11:01:41+00:00

Add atomic operation support for i8 and i16 types using volatile
read/write and smp_load_acquire/smp_store_release helpers.

[boqun: Adjust [1] to avoid introduction of
impl_atomic_only_load_and_store_ops!() in the middle]

Signed-off-by: FUJITA Tomonori 
Reviewed-by: Gary Guo 
Reviewed-by: Joel Fernandes 
Link: https://lore.kernel.org/all/20251228120546.1602275-1-fujita.tomonori@gmail.com/ [1]
Signed-off-by: Boqun Feng 
Link: https://patch.msgid.link/20251211113826.1299077-4-fujita.tomonori@gmail.com

rust: sync: atomic: Prepare AtomicOps macros for i8/i16 support

2026-01-09T11:01:41+00:00

Rework the internal AtomicOps macro plumbing to generate per-type
implementations from a mapping list.

Capture the trait definition once and reuse it for both declaration
and per-type impl expansion to reduce duplication and keep future
extensions simple.

This is a preparatory refactor for enabling i8/i16 atomics cleanly.

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Boqun Feng 
Link: https://patch.msgid.link/20251228120546.1602275-2-fujita.tomonori@gmail.com

rust: sync: Add basic atomic operation mapping framework

2025-09-15T07:38:32+00:00

Preparation for generic atomic implementation. To unify the
implementation of a generic method over `i32` and `i64`, the C side
atomic methods need to be grouped so that in a generic method, they can
be referred as ::, otherwise their parameters and return
value are different between `i32` and `i64`, which would require using
`transmute()` to unify the type into a `T`.

Introduce `AtomicImpl` to represent a basic type in Rust that has the
direct mapping to an atomic implementation from C. Use a sealed trait to
restrict `AtomicImpl` to only support `i32` and `i64` for now.

Further, different methods are put into different `*Ops` trait groups,
and this is for the future when smaller types like `i8`/`i16` are
supported but only with a limited set of API (e.g. only set(), load(),
xchg() and cmpxchg(), no add() or sub() etc).

While the atomic mod is introduced, documentation is also added for
memory models and data races.

Also bump my role to the maintainer of ATOMIC INFRASTRUCTURE to reflect
my responsibility on the Rust atomic mod.

Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Alice Ryhl 
Reviewed-by: Benno Lossin 
Reviewed-by: Elle Rhumsaa 
Link: https://lore.kernel.org/all/20250719030827.61357-3-boqun.feng@gmail.com/