From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Boqun Feng" <boqun.feng@gmail.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
lkmm@lists.linux.dev, linux-arch@vger.kernel.org,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Lyude Paul" <lyude@redhat.com>, "Ingo Molnar" <mingo@kernel.org>,
"Mitchell Levy" <levymitchell0@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [PATCH v5 04/10] rust: sync: atomic: Add generic atomics
Date: Thu, 26 Jun 2025 14:15:35 +0200 [thread overview]
Message-ID: <8734bm1yxk.fsf@kernel.org> (raw)
In-Reply-To: <20250618164934.19817-5-boqun.feng@gmail.com> (Boqun Feng's message of "Wed, 18 Jun 2025 09:49:28 -0700")
"Boqun Feng" <boqun.feng@gmail.com> writes:
[...]
> +
> +impl<T: AllowAtomic> Atomic<T> {
> + /// Creates a new atomic.
> + pub const fn new(v: T) -> Self {
> + Self(Opaque::new(v))
> + }
> +
> + /// Creates a reference to [`Self`] from a pointer.
> + ///
> + /// # Safety
> + ///
> + /// - `ptr` has to be a valid pointer.
> + /// - `ptr` has to be valid for both reads and writes for the whole lifetime `'a`.
> + /// - For the whole lifetime of '`a`, other accesses to the object cannot cause data races
> + /// (defined by [`LKMM`]) against atomic operations on the returned reference.
I feel the wording is a bit tangled here. How about something along the
lines of
For the duration of `'a`, all accesses to the object must be atomic.
> + ///
> + /// [`LKMM`]: srctree/tools/memory-model
> + ///
> + /// # Examples
> + ///
> + /// Using [`Atomic::from_ptr()`] combined with [`Atomic::load()`] or [`Atomic::store()`] can
> + /// achieve the same functionality as `READ_ONCE()`/`smp_load_acquire()` or
> + /// `WRITE_ONCE()`/`smp_store_release()` in C side:
> + ///
> + /// ```rust
> + /// # use kernel::types::Opaque;
> + /// use kernel::sync::atomic::{Atomic, Relaxed, Release};
> + ///
> + /// // Assume there is a C struct `Foo`.
> + /// mod cbindings {
> + /// #[repr(C)]
> + /// pub(crate) struct foo { pub(crate) a: i32, pub(crate) b: i32 }
> + /// }
> + ///
> + /// let tmp = Opaque::new(cbindings::foo { a: 1, b: 2});
> + ///
> + /// // struct foo *foo_ptr = ..;
> + /// let foo_ptr = tmp.get();
> + ///
> + /// // SAFETY: `foo_ptr` is a valid pointer, and `.a` is inbound.
Did you mean to say "in bounds"? Or what is "inbound"?
> + /// let foo_a_ptr = unsafe { core::ptr::addr_of_mut!((*foo_ptr).a) };
This should be `&raw mut` by now, right?
> + ///
> + /// // a = READ_ONCE(foo_ptr->a);
> + /// //
> + /// // SAFETY: `foo_a_ptr` is a valid pointer for read, and all accesses on it is atomic, so no
> + /// // data race.
> + /// let a = unsafe { Atomic::from_ptr(foo_a_ptr) }.load(Relaxed);
> + /// # assert_eq!(a, 1);
> + ///
> + /// // smp_store_release(&foo_ptr->a, 2);
> + /// //
> + /// // SAFETY: `foo_a_ptr` is a valid pointer for write, and all accesses on it is atomic, so no
> + /// // data race.
> + /// unsafe { Atomic::from_ptr(foo_a_ptr) }.store(2, Release);
> + /// ```
> + ///
> + /// However, this should be only used when communicating with C side or manipulating a C struct.
> + pub unsafe fn from_ptr<'a>(ptr: *mut T) -> &'a Self
> + where
> + T: Sync,
> + {
> + // CAST: `T` is transparent to `Atomic<T>`.
> + // SAFETY: Per function safety requirement, `ptr` is a valid pointer and the object will
> + // live long enough. It's safe to return a `&Atomic<T>` because function safety requirement
> + // guarantees other accesses won't cause data races.
> + unsafe { &*ptr.cast::<Self>() }
> + }
> +
> + /// Returns a pointer to the underlying atomic variable.
> + ///
> + /// Extra safety requirement on using the return pointer: the operations done via the pointer
> + /// cannot cause data races defined by [`LKMM`].
> + ///
> + /// [`LKMM`]: srctree/tools/memory-model
> + pub const fn as_ptr(&self) -> *mut T {
> + self.0.get()
> + }
> +
> + /// Returns a mutable reference to the underlying atomic variable.
> + ///
> + /// This is safe because the mutable reference of the atomic variable guarantees the exclusive
> + /// access.
> + pub fn get_mut(&mut self) -> &mut T {
> + // SAFETY: `self.as_ptr()` is a valid pointer to `T`, and the object has already been
> + // initialized. `&mut self` guarantees the exclusive access, so it's safe to reborrow
> + // mutably.
> + unsafe { &mut *self.as_ptr() }
> + }
> +}
> +
> +impl<T: AllowAtomic> Atomic<T>
> +where
> + T::Repr: AtomicHasBasicOps,
> +{
> + /// Loads the value from the atomic variable.
> + ///
> + /// # Examples
> + ///
> + /// Simple usages:
> + ///
> + /// ```rust
> + /// use kernel::sync::atomic::{Atomic, Relaxed};
> + ///
> + /// let x = Atomic::new(42i32);
> + ///
> + /// assert_eq!(42, x.load(Relaxed));
> + ///
> + /// let x = Atomic::new(42i64);
> + ///
> + /// assert_eq!(42, x.load(Relaxed));
> + /// ```
> + ///
> + /// Customized new types in [`Atomic`]:
> + ///
> + /// ```rust
> + /// use kernel::sync::atomic::{generic::AllowAtomic, Atomic, Relaxed};
> + ///
> + /// #[derive(Clone, Copy)]
> + /// #[repr(transparent)]
> + /// struct NewType(u32);
> + ///
> + /// // SAFETY: `NewType` is transparent to `u32`, which has the same size and alignment as
> + /// // `i32`.
> + /// unsafe impl AllowAtomic for NewType {
> + /// type Repr = i32;
> + ///
> + /// fn into_repr(self) -> Self::Repr {
> + /// self.0 as i32
> + /// }
> + ///
> + /// fn from_repr(repr: Self::Repr) -> Self {
> + /// NewType(repr as u32)
> + /// }
> + /// }
> + ///
> + /// let n = Atomic::new(NewType(0));
> + ///
> + /// assert_eq!(0, n.load(Relaxed).0);
> + /// ```
> + #[doc(alias("atomic_read", "atomic64_read"))]
> + #[inline(always)]
> + pub fn load<Ordering: AcquireOrRelaxed>(&self, _: Ordering) -> T {
> + let a = self.as_ptr().cast::<T::Repr>();
> +
> + // SAFETY:
> + // - For calling the atomic_read*() function:
> + // - `self.as_ptr()` is a valid pointer, and per the safety requirement of `AllocAtomic`,
Typo `AllocAtomic`.
> + // a `*mut T` is a valid `*mut T::Repr`. Therefore `a` is a valid pointer,
> + // - per the type invariants, the following atomic operation won't cause data races.
> + // - For extra safety requirement of usage on pointers returned by `self.as_ptr():
> + // - atomic operations are used here.
> + let v = unsafe {
> + if Ordering::IS_RELAXED {
> + T::Repr::atomic_read(a)
> + } else {
> + T::Repr::atomic_read_acquire(a)
> + }
> + };
> +
> + T::from_repr(v)
> + }
> +
> + /// Stores a value to the atomic variable.
> + ///
> + /// # Examples
> + ///
> + /// ```rust
> + /// use kernel::sync::atomic::{Atomic, Relaxed};
> + ///
> + /// let x = Atomic::new(42i32);
> + ///
> + /// assert_eq!(42, x.load(Relaxed));
> + ///
> + /// x.store(43, Relaxed);
> + ///
> + /// assert_eq!(43, x.load(Relaxed));
> + /// ```
> + ///
> + #[doc(alias("atomic_set", "atomic64_set"))]
> + #[inline(always)]
> + pub fn store<Ordering: ReleaseOrRelaxed>(&self, v: T, _: Ordering) {
> + let v = T::into_repr(v);
> + let a = self.as_ptr().cast::<T::Repr>();
> +
> + // SAFETY:
> + // - For calling the atomic_set*() function:
> + // - `self.as_ptr()` is a valid pointer, and per the safety requirement of `AllocAtomic`,
Typo `AllocAtomic`.
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-06-26 12:15 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 16:49 [PATCH v5 00/10] LKMM generic atomics in Rust Boqun Feng
2025-06-18 16:49 ` [PATCH v5 01/10] rust: Introduce atomic API helpers Boqun Feng
2025-06-26 8:44 ` Andreas Hindborg
2025-06-27 14:00 ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 02/10] rust: sync: Add basic atomic operation mapping framework Boqun Feng
2025-06-26 8:50 ` Andreas Hindborg
2025-06-26 10:17 ` Andreas Hindborg
2025-06-27 14:30 ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 03/10] rust: sync: atomic: Add ordering annotation types Boqun Feng
2025-06-19 10:31 ` Peter Zijlstra
2025-06-19 12:19 ` Alice Ryhl
2025-06-19 13:29 ` Boqun Feng
2025-06-19 14:32 ` Peter Zijlstra
2025-06-19 15:00 ` Boqun Feng
2025-06-19 15:10 ` Peter Zijlstra
2025-06-19 15:15 ` Boqun Feng
2025-06-19 18:04 ` Alan Stern
2025-06-21 11:18 ` Gary Guo
2025-06-23 2:48 ` Boqun Feng
2025-06-26 12:36 ` Andreas Hindborg
2025-06-27 14:34 ` Boqun Feng
2025-06-27 14:44 ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 04/10] rust: sync: atomic: Add generic atomics Boqun Feng
2025-06-21 11:32 ` Gary Guo
2025-06-23 5:19 ` Boqun Feng
2025-06-23 11:54 ` Benno Lossin
2025-06-23 12:58 ` Boqun Feng
2025-06-23 18:30 ` Gary Guo
2025-06-23 19:09 ` Boqun Feng
2025-06-23 23:27 ` Benno Lossin
2025-06-24 16:35 ` Boqun Feng
2025-06-26 13:54 ` Benno Lossin
2025-07-04 21:22 ` Boqun Feng
2025-07-04 22:05 ` Benno Lossin
2025-07-04 22:30 ` Boqun Feng
2025-07-04 22:49 ` Benno Lossin
2025-07-04 23:21 ` Boqun Feng
2025-07-04 20:25 ` Boqun Feng
2025-07-04 20:45 ` Benno Lossin
2025-07-04 21:17 ` Boqun Feng
2025-07-04 22:38 ` Benno Lossin
2025-07-04 23:21 ` Boqun Feng
2025-07-05 8:04 ` Benno Lossin
2025-07-05 15:38 ` Boqun Feng
2025-07-05 21:43 ` Benno Lossin
2025-06-26 12:15 ` Andreas Hindborg [this message]
2025-06-27 15:01 ` Boqun Feng
2025-06-30 9:52 ` Andreas Hindborg
2025-06-30 14:44 ` Alan Stern
2025-07-01 8:54 ` Andreas Hindborg
2025-07-01 14:50 ` Boqun Feng
2025-07-02 8:33 ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 05/10] rust: sync: atomic: Add atomic {cmp,}xchg operations Boqun Feng
2025-06-21 11:37 ` Gary Guo
2025-06-23 5:23 ` Boqun Feng
2025-06-26 13:12 ` Andreas Hindborg
2025-06-28 3:03 ` Boqun Feng
2025-06-30 10:16 ` Andreas Hindborg
2025-06-30 14:51 ` Alan Stern
2025-06-30 15:12 ` Boqun Feng
2025-06-27 8:58 ` Benno Lossin
2025-06-27 13:53 ` Boqun Feng
2025-06-28 6:12 ` Benno Lossin
2025-06-28 7:31 ` Boqun Feng
2025-06-28 8:00 ` Benno Lossin
2025-06-30 15:24 ` Boqun Feng
2025-06-30 15:27 ` Boqun Feng
2025-06-30 15:50 ` Benno Lossin
2025-06-18 16:49 ` [PATCH v5 06/10] rust: sync: atomic: Add the framework of arithmetic operations Boqun Feng
2025-06-21 11:41 ` Gary Guo
2025-06-26 12:39 ` Andreas Hindborg
2025-06-28 3:04 ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 07/10] rust: sync: atomic: Add Atomic<u{32,64}> Boqun Feng
2025-06-26 12:47 ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 08/10] rust: sync: atomic: Add Atomic<{usize,isize}> Boqun Feng
2025-06-26 12:49 ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 09/10] rust: sync: atomic: Add Atomic<*mut T> Boqun Feng
2025-06-18 16:49 ` [PATCH v5 10/10] rust: sync: Add memory barriers Boqun Feng
2025-06-26 13:36 ` Andreas Hindborg
2025-06-28 3:42 ` Boqun Feng
2025-06-30 9:54 ` Andreas Hindborg
2025-06-18 20:22 ` [PATCH v5 00/10] LKMM generic atomics in Rust Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734bm1yxk.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=levymitchell0@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=torvalds@linux-foundation.org \
--cc=viresh.kumar@linaro.org \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.