rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Tamir Duberstein <tamird@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Wedson Almeida Filho" <walmeida@microsoft.com>,
	"Alex Mantel" <alexmantel93@mailbox.org>,
	"Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] rust: convert `Arc` to use `Refcount`
Date: Fri, 21 Feb 2025 16:14:39 +0000	[thread overview]
Message-ID: <20250221161439.0e34fba9@eugeo> (raw)
In-Reply-To: <CAJ-ks9npk8oSFHZHdViR1XhF+A8e2L+P0wCgmjE7mzAxS9WK1g@mail.gmail.com>

On Wed, 19 Feb 2025 17:12:10 -0500
Tamir Duberstein <tamird@gmail.com> wrote:

> On Wed, Feb 19, 2025 at 3:17 PM Gary Guo <gary@garyguo.net> wrote:
> >
> > With `Refcount` type created, `Arc` can use `Refcount` instead of
> > calling into FFI directly.
> >
> > Signed-off-by: Gary Guo <gary@garyguo.net>
> > ---
> >  rust/kernel/sync/arc.rs | 65 +++++++++++++++++------------------------
> >  1 file changed, 26 insertions(+), 39 deletions(-)
> >
> > diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> > index 3cefda7a4372..1f5fbc6b3742 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,10 +18,10 @@
> >
> >  use crate::{
> >      alloc::{AllocError, Flags, KBox},
> > -    bindings,
> >      init::{self, InPlaceInit, Init, PinInit},
> > +    sync::Refcount,
> >      try_init,
> > -    types::{ForeignOwnable, Opaque},
> > +    types::ForeignOwnable,
> >  };
> >  use core::{
> >      alloc::Layout,
> > @@ -143,7 +143,7 @@ pub struct Arc<T: ?Sized> {
> >  #[pin_data]
> >  #[repr(C)]
> >  struct ArcInner<T: ?Sized> {
> > -    refcount: Opaque<bindings::refcount_t>,
> > +    refcount: Refcount,
> >      data: T,
> >  }
> >
> > @@ -155,7 +155,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
> > @@ -207,8 +207,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,
> >          };
> >
> > @@ -290,7 +289,7 @@ pub fn ptr_eq(this: &Self, other: &Self) -> bool {
> >      /// use kernel::sync::{Arc, UniqueArc};
> >      ///
> >      /// let arc = Arc::new(42, GFP_KERNEL)?;
> > -    /// let unique_arc = arc.into_unique_or_drop();
> > +    /// let unique_arc = Arc::into_unique_or_drop(arc);
> >      ///
> >      /// // The above conversion should succeed since refcount of `arc` is 1.
> >      /// assert!(unique_arc.is_some());
> > @@ -306,35 +305,30 @@ pub fn ptr_eq(this: &Self, other: &Self) -> bool {
> >      /// let arc = Arc::new(42, GFP_KERNEL)?;
> >      /// let another = arc.clone();
> >      ///
> > -    /// let unique_arc = arc.into_unique_or_drop();
> > +    /// let unique_arc = Arc::into_unique_or_drop(arc);
> >      ///
> >      /// // The above conversion should fail since refcount of `arc` is >1.
> >      /// assert!(unique_arc.is_none());
> >      ///
> >      /// # Ok::<(), Error>(())
> >      /// ```
> > -    pub fn into_unique_or_drop(self) -> Option<Pin<UniqueArc<T>>> {
> > +    pub fn into_unique_or_drop(this: Self) -> Option<Pin<UniqueArc<T>>> {  
> 
> Why did this signature need to change?

I think I mentioned this in a earlier series. Smart pointers are not
supposed to have methods (i.e. with a self receiver) as it may shadow
deref'ed functions.

> 
> >          // We will manually manage the refcount in this method, so we disable the destructor.
> > -        let me = ManuallyDrop::new(self);
> > +        let this = ManuallyDrop::new(this);
> >          // SAFETY: We own a refcount, so the pointer is still valid.
> > -        let refcount = unsafe { me.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);  
> 
> We could retain the unsynchronized operation here by taking a mutable
> reference above and writing through it. Right? Could we remove `set`
> from the abstraction in the previous patch?

This was suggested as well in a previous series but I don't think it's
a good idea. Creating a mutable reference and using unsynchronized
write requires `unsafe`. `set` doesn't.

Note that the `set` here is relaxed order. I doubt (if things are
inlined properly) there'll be any codegen difference with a completely
unsynchronized write.

Not having an additional unsafe is a good trade-off to me.

> 
> >
> > -            // 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
> > -            // their values.
> > +            // INVARIANT: If the refcount failed to decrement because it is 1, then we have the
> > +            // exclusive ownership, so we may create a `UniqueArc`. We must pin the `UniqueArc`
> > +            // because the values was previously in an `Arc`, and they pin their values.  
> 
> Pre-existing typo you're taking ownership of: "the values" should be
> "the value". But why touch this comment at all?

I think this is a left-over that I forget to undo.

> 
> >              Some(Pin::from(UniqueArc {
> > -                inner: ManuallyDrop::into_inner(me),
> > +                inner: ManuallyDrop::into_inner(this),
> >              }))
> >          } else {
> >              None
> > @@ -396,14 +390,10 @@ fn as_ref(&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) }
> > @@ -412,16 +402,14 @@ 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.
> > +        // NOTE: 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. However it is okay
> > +        // to have a transient reference to decrement the refcount, see
> > +        // https://github.com/rust-lang/rust/issues/55005.
> > +        let is_zero = unsafe { self.ptr.as_ref().refcount.dec_and_test() };  
> 
> How come this careful handling is not required in into_unique_or_drop?
> At least, the SAFETY comment there is much more mundane.

Because `into_unique_or_drop` doesn't actually remove the allocation
(it only decrements refcount for non-zero or turn it into `UniqueArc`).

> 
> >          if is_zero {
> >              // The count reached zero, we must free the memory.
> >              //
> > @@ -673,8 +661,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 <- init::uninit::<T, AllocError>(),
> >              }? AllocError),
> >              flags,
> > --
> > 2.47.2
> >  


  reply	other threads:[~2025-02-21 16:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 20:15 [PATCH v3 0/4] implement `kernel::sync::Refcount` and convert users Gary Guo
2025-02-19 20:15 ` [PATCH v3 1/4] rust: implement `kernel::sync::Refcount` Gary Guo
2025-02-19 22:12   ` Tamir Duberstein
2025-02-21 16:02     ` Gary Guo
2025-02-21 17:23       ` Tamir Duberstein
2025-02-20 12:46   ` Fiona Behrens
2025-02-19 20:15 ` [PATCH v3 2/4] rust: convert `Arc` to use `Refcount` Gary Guo
2025-02-19 22:12   ` Tamir Duberstein
2025-02-21 16:14     ` Gary Guo [this message]
2025-02-21 17:27       ` Tamir Duberstein
2025-02-21 18:28         ` Gary Guo
2025-02-21 18:33           ` Tamir Duberstein
2025-02-21 12:05   ` Alice Ryhl
2025-02-19 20:15 ` [PATCH v3 3/4] rust: block: convert `block::mq` " Gary Guo
2025-02-19 22:26   ` Tamir Duberstein
2025-02-19 22:53     ` Tamir Duberstein
2025-02-20 19:18       ` Andreas Hindborg
2025-02-20 12:27   ` David Gow
2025-02-19 20:15 ` [PATCH v3 4/4] MAINTAINERS: update atomic infrastructure entry to include Rust Gary Guo
2025-02-19 21:13   ` 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=20250221161439.0e34fba9@eugeo \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=alexmantel93@mailbox.org \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@gmail.com \
    --cc=tmgross@umich.edu \
    --cc=walmeida@microsoft.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 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).