rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elle Rhumsaa <elle@weathered-steel.dev>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	lkmm@lists.linux.dev, "Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	stern@rowland.harvard.edu, "Miguel Ojeda" <ojeda@kernel.org>,
	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>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>
Subject: Re: [PATCH 12/14] rust: convert `Arc` to use `Refcount`
Date: Sat, 6 Sep 2025 04:26:01 +0000	[thread overview]
Message-ID: <aLu32WE1La5eEdnS@archiso> (raw)
In-Reply-To: <20250905044141.77868-13-boqun.feng@gmail.com>

On Thu, Sep 04, 2025 at 09:41:39PM -0700, Boqun Feng wrote:
> From: Gary Guo <gary@garyguo.net>
> 
> With `Refcount` type created, `Arc` can use `Refcount` instead of
> calling into FFI directly.
> 
> Signed-off-by: Gary Guo <gary@garyguo.net>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Benno Lossin <lossin@kernel.org>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Link: https://lore.kernel.org/r/20250723233312.3304339-4-gary@kernel.org
> ---
>  rust/kernel/sync/arc.rs | 45 +++++++++++++----------------------------
>  1 file changed, 14 insertions(+), 31 deletions(-)
> 
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index 4ee155b43b2d..9298993ea7d8 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -8,7 +8,7 @@
>  //! threads.
>  //!
>  //! It is different from the standard library's [`Arc`] in a few ways:
> -//! 1. It is backed by the kernel's `refcount_t` type.
> +//! 1. It is backed by the kernel's [`Refcount`] type.
>  //! 2. It does not support weak references, which allows it to be half the size.
>  //! 3. It saturates the reference count instead of aborting when it goes over a threshold.
>  //! 4. It does not provide a `get_mut` method, so the ref counted object is pinned.
> @@ -18,11 +18,11 @@
>  
>  use crate::{
>      alloc::{AllocError, Flags, KBox},
> -    bindings,
>      ffi::c_void,
>      init::InPlaceInit,
> +    sync::Refcount,
>      try_init,
> -    types::{ForeignOwnable, Opaque},
> +    types::ForeignOwnable,
>  };
>  use core::{
>      alloc::Layout,
> @@ -145,7 +145,7 @@ pub struct Arc<T: ?Sized> {
>  #[pin_data]
>  #[repr(C)]
>  struct ArcInner<T: ?Sized> {
> -    refcount: Opaque<bindings::refcount_t>,
> +    refcount: Refcount,
>      data: T,
>  }
>  
> @@ -157,7 +157,7 @@ impl<T: ?Sized> ArcInner<T> {
>      /// `ptr` must have been returned by a previous call to [`Arc::into_raw`], and the `Arc` must
>      /// not yet have been destroyed.
>      unsafe fn container_of(ptr: *const T) -> NonNull<ArcInner<T>> {
> -        let refcount_layout = Layout::new::<bindings::refcount_t>();
> +        let refcount_layout = Layout::new::<Refcount>();
>          // SAFETY: The caller guarantees that the pointer is valid.
>          let val_layout = Layout::for_value(unsafe { &*ptr });
>          // SAFETY: We're computing the layout of a real struct that existed when compiling this
> @@ -229,8 +229,7 @@ impl<T> Arc<T> {
>      pub fn new(contents: T, flags: Flags) -> Result<Self, AllocError> {
>          // INVARIANT: The refcount is initialised to a non-zero value.
>          let value = ArcInner {
> -            // SAFETY: There are no safety requirements for this FFI call.
> -            refcount: Opaque::new(unsafe { bindings::REFCOUNT_INIT(1) }),
> +            refcount: Refcount::new(1),
>              data: contents,
>          };
>  
> @@ -348,18 +347,13 @@ pub fn into_unique_or_drop(this: Self) -> Option<Pin<UniqueArc<T>>> {
>          // We will manually manage the refcount in this method, so we disable the destructor.
>          let this = ManuallyDrop::new(this);
>          // SAFETY: We own a refcount, so the pointer is still valid.
> -        let refcount = unsafe { this.ptr.as_ref() }.refcount.get();
> +        let refcount = unsafe { &this.ptr.as_ref().refcount };
>  
>          // If the refcount reaches a non-zero value, then we have destroyed this `Arc` and will
>          // return without further touching the `Arc`. If the refcount reaches zero, then there are
>          // no other arcs, and we can create a `UniqueArc`.
> -        //
> -        // SAFETY: We own a refcount, so the pointer is not dangling.
> -        let is_zero = unsafe { bindings::refcount_dec_and_test(refcount) };
> -        if is_zero {
> -            // SAFETY: We have exclusive access to the arc, so we can perform unsynchronized
> -            // accesses to the refcount.
> -            unsafe { core::ptr::write(refcount, bindings::REFCOUNT_INIT(1)) };
> +        if refcount.dec_and_test() {
> +            refcount.set(1);
>  
>              // INVARIANT: We own the only refcount to this arc, so we may create a `UniqueArc`. We
>              // must pin the `UniqueArc` because the values was previously in an `Arc`, and they pin
> @@ -456,14 +450,10 @@ fn borrow(&self) -> &T {
>  
>  impl<T: ?Sized> Clone for Arc<T> {
>      fn clone(&self) -> Self {
> -        // SAFETY: By the type invariant, there is necessarily a reference to the object, so it is
> -        // safe to dereference it.
> -        let refcount = unsafe { self.ptr.as_ref() }.refcount.get();
> -
> -        // INVARIANT: C `refcount_inc` saturates the refcount, so it cannot overflow to zero.
> +        // INVARIANT: `Refcount` saturates the refcount, so it cannot overflow to zero.
>          // SAFETY: By the type invariant, there is necessarily a reference to the object, so it is
>          // safe to increment the refcount.
> -        unsafe { bindings::refcount_inc(refcount) };
> +        unsafe { self.ptr.as_ref() }.refcount.inc();
>  
>          // SAFETY: We just incremented the refcount. This increment is now owned by the new `Arc`.
>          unsafe { Self::from_inner(self.ptr) }
> @@ -472,16 +462,10 @@ fn clone(&self) -> Self {
>  
>  impl<T: ?Sized> Drop for Arc<T> {
>      fn drop(&mut self) {
> -        // SAFETY: By the type invariant, there is necessarily a reference to the object. We cannot
> -        // touch `refcount` after it's decremented to a non-zero value because another thread/CPU
> -        // may concurrently decrement it to zero and free it. It is ok to have a raw pointer to
> -        // freed/invalid memory as long as it is never dereferenced.
> -        let refcount = unsafe { self.ptr.as_ref() }.refcount.get();
> -
>          // INVARIANT: If the refcount reaches zero, there are no other instances of `Arc`, and
>          // this instance is being dropped, so the broken invariant is not observable.
> -        // SAFETY: Also by the type invariant, we are allowed to decrement the refcount.
> -        let is_zero = unsafe { bindings::refcount_dec_and_test(refcount) };
> +        // SAFETY: By the type invariant, there is necessarily a reference to the object.
> +        let is_zero = unsafe { self.ptr.as_ref() }.refcount.dec_and_test();
>          if is_zero {
>              // The count reached zero, we must free the memory.
>              //
> @@ -775,8 +759,7 @@ pub fn new_uninit(flags: Flags) -> Result<UniqueArc<MaybeUninit<T>>, AllocError>
>          // INVARIANT: The refcount is initialised to a non-zero value.
>          let inner = KBox::try_init::<AllocError>(
>              try_init!(ArcInner {
> -                // SAFETY: There are no safety requirements for this FFI call.
> -                refcount: Opaque::new(unsafe { bindings::REFCOUNT_INIT(1) }),
> +                refcount: Refcount::new(1),
>                  data <- pin_init::uninit::<T, AllocError>(),
>              }? AllocError),
>              flags,
> -- 
> 2.51.0
> 
> 

Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>

  reply	other threads:[~2025-09-06  4:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05  4:41 [GIT PULL] [PATCH 00/14] Rust atomic changes for v6.18 Boqun Feng
2025-09-05  4:41 ` [PATCH 01/14] rust: Introduce atomic API helpers Boqun Feng
2025-09-06  4:22   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 02/14] rust: sync: Add basic atomic operation mapping framework Boqun Feng
2025-09-06  4:22   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 03/14] rust: sync: atomic: Add ordering annotation types Boqun Feng
2025-09-06  4:22   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 04/14] rust: sync: atomic: Add generic atomics Boqun Feng
2025-09-06  4:23   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 05/14] rust: sync: atomic: Add atomic {cmp,}xchg operations Boqun Feng
2025-09-06  4:23   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 06/14] rust: sync: atomic: Add the framework of arithmetic operations Boqun Feng
2025-09-06  4:23   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 07/14] rust: sync: atomic: Add Atomic<u{32,64}> Boqun Feng
2025-09-06  4:24   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 08/14] rust: sync: atomic: Add Atomic<{usize,isize}> Boqun Feng
2025-09-06  4:24   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 09/14] rust: sync: Add memory barriers Boqun Feng
2025-09-06  4:25   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 10/14] rust: implement `kernel::sync::Refcount` Boqun Feng
2025-09-06  4:25   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 11/14] rust: make `Arc::into_unique_or_drop` associated function Boqun Feng
2025-09-06  4:25   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 12/14] rust: convert `Arc` to use `Refcount` Boqun Feng
2025-09-06  4:26   ` Elle Rhumsaa [this message]
2025-09-05  4:41 ` [PATCH 13/14] rust: block: convert `block::mq` " Boqun Feng
2025-09-06  4:26   ` Elle Rhumsaa
2025-09-05  4:41 ` [PATCH 14/14] MAINTAINERS: update atomic infrastructure entry to include Rust Boqun Feng
2025-09-06  4:26   ` Elle Rhumsaa
2025-09-10  5:27 ` [GIT PULL] [PATCH 00/14] Rust atomic changes for v6.18 Boqun Feng

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=aLu32WE1La5eEdnS@archiso \
    --to=elle@weathered-steel.dev \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --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=linux-kernel@vger.kernel.org \
    --cc=lkmm@lists.linux.dev \
    --cc=lossin@kernel.org \
    --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=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).