[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLu3woBof86sNuIx@archiso>
Date: Sat, 6 Sep 2025 04:25:38 +0000
From: Elle Rhumsaa <elle@...thered-steel.dev>
To: Boqun Feng <boqun.feng@...il.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
lkmm@...ts.linux.dev, Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E. McKenney" <paulmck@...nel.org>, stern@...land.harvard.edu,
Miguel Ojeda <ojeda@...nel.org>, alex.gaynor@...il.com,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH 11/14] rust: make `Arc::into_unique_or_drop` associated
function
On Thu, Sep 04, 2025 at 09:41:38PM -0700, Boqun Feng wrote:
> From: Gary Guo <gary@...yguo.net>
>
> Make `Arc::into_unique_or_drop` to become a mere associated function
> instead of a method (i.e. removing the `self` receiver).
>
> It's a general convention for Rust smart pointers to avoid having
> methods defined on them, because if the pointee type has a method of the
> same name, then it is shadowed. This is normally for avoiding semver
> breakage, which isn't an issue for kernel codebase, but it's still
> generally a good practice to follow this rule, so that `ptr.foo()` would
> always be calling a method on the pointee type.
>
> Reviewed-by: Benno Lossin <lossin@...nel.org>
> Signed-off-by: Gary Guo <gary@...yguo.net>
> Reviewed-by: Alexandre Courbot <acourbot@...dia.com>
> Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> Link: https://lore.kernel.org/r/20250723233312.3304339-3-gary@kernel.org
> ---
> rust/kernel/sync/arc.rs | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index 63a66761d0c7..4ee155b43b2d 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -321,7 +321,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());
> @@ -337,18 +337,18 @@ 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>>> {
> // 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.get();
>
> // 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
> @@ -365,7 +365,7 @@ pub fn into_unique_or_drop(self) -> Option<Pin<UniqueArc<T>>> {
> // must pin the `UniqueArc` because the values was previously in an `Arc`, and they pin
> // their values.
> Some(Pin::from(UniqueArc {
> - inner: ManuallyDrop::into_inner(me),
> + inner: ManuallyDrop::into_inner(this),
> }))
> } else {
> None
> --
> 2.51.0
>
>
Reviewed-by: Elle Rhumsaa <elle@...thered-steel.dev>
Powered by blists - more mailing lists