Re: [PATCH v8 4/9] rust: sync: atomic: Add generic atomics

"Benno Lossin" <[email protected]> Tue, 12 Aug 2025 09:59:39 +0200
Newsgroups dev.linux.lists.lkmm,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Sat Jul 19, 2025 at 5:08 AM CEST, Boqun Feng wrote:
> To provide using LKMM atomics for Rust code, a generic `Atomic<T>` is
> added, currently `T` needs to be Send + Copy because these are the
> straightforward usages and all basic types support this.
>
> Implement `AtomicType` for `i32` and `i64`, and so far only basic
> operations load() and store() are introduced.
>
> Reviewed-by: Alice Ryhl <[email protected]>
> Signed-off-by: Boqun Feng <[email protected]>

Reviewed-by: Benno Lossin <[email protected]>

> ---
>  rust/kernel/sync/atomic.rs           | 274 +++++++++++++++++++++++++++
>  rust/kernel/sync/atomic/predefine.rs |  15 ++
>  2 files changed, 289 insertions(+)
>  create mode 100644 rust/kernel/sync/atomic/predefine.rs

> +/// # Limitations
> +///
> +/// Because C primitives are used to implement the atomic operations, and a C function requires a
> +/// valid object of a type to operate on (i.e. no `MaybeUninit<_>`), hence at the Rust <-> C
> +/// surface, only types with all the bits initialized can be passed. As a result, types like `(u8,
> +/// u16)` (padding bytes are uninitialized) are currently not supported. Note that technically
> +/// these types can be supported if some APIs are removed for them and the inner implementation is
> +/// tweaked, but the justification of support such a type is not strong enough at the moment. This
> +/// should be resolved if there is an implementation for `MaybeUninit<i32>` as `AtomicImpl`.

I'd remove the last sentence, as it makes it sound like one only would
have to add that impl and be finished.

---
Cheers,
Benno