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
> >
next prev parent 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 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.