From: Shankari Anand <shankari.ak0208@gmail.com>
To: Benno Lossin <lossin@kernel.org>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
patches@lists.linux.dev, Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
Roy Baron <bjorn3_gh@protonmail.com>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>,
Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH v2 1/2] rust: move ARef and AlwaysRefCounted to sync::aref
Date: Thu, 26 Jun 2025 19:25:00 +0530 [thread overview]
Message-ID: <CAPRMd3=5aMx_DmhuXxWbNodM8OV6EWkXMTByAzOSr3ESoSj_BQ@mail.gmail.com> (raw)
In-Reply-To: <DAVYWQE2PYZE.3TRIT906A9BJM@kernel.org>
Hello,
Thanks for your feedback!
> I'd say this module is about supporting objects with builtin reference
> counting.
I described the module as an "Atomic reference-counted pointer
abstraction" to highlight its similarity to Arc<T>, but for manually
refcounted types. Your version about “supporting objects with built-in
reference counting” is definitely clearer, happy to adopt that
phrasing if preferred.
> I would lead with comparing `ARef<T>` to `Arc<T>` and only later mention
> `AlwaysRefCounted`.
I mentioned AlwaysRefCounted early on just to give readers a quick
idea of what the module is really about, but I understand your point
about introducing it a bit later and can rearrange that.
>
> You also rephrased these docs, can you do that in a separate patch?
I rephrased a few lines in the intro since we’re starting a new module
and I thought it might help with readability. But if keeping the
original is better, I can revert those changes, no problem at all.
> Newline?
About the extra newline - I didn’t add it manually, but it might’ve
come from creating the new file. I’ll check the patch, and if it was
actually added, I’ll remove it.
> ---
> Cheers,
> Benno
---
Thanks and regards,
Shankari
On Thu, Jun 26, 2025 at 3:59 AM Benno Lossin <lossin@kernel.org> wrote:
>
> On Wed Jun 25, 2025 at 1:11 PM CEST, Shankari Anand wrote:
> > diff --git a/rust/kernel/sync/aref.rs b/rust/kernel/sync/aref.rs
> > new file mode 100644
> > index 000000000000..93a23b493e21
> > --- /dev/null
> > +++ b/rust/kernel/sync/aref.rs
> > @@ -0,0 +1,170 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +//! Atomic reference-counted pointer abstraction.
>
> I'd say this module is about supporting objects with builtin reference
> counting.
>
> > +//!
> > +//! This module provides [`ARef<T>`], an owned reference to a value that implements
> > +//! [`AlwaysRefCounted`] — an unsafe trait for types that manage their own reference count.
>
> I would lead with comparing `ARef<T>` to `Arc<T>` and only later mention
> `AlwaysRefCounted`.
>
> > +//!
> > +//! It is based on the Linux kernel's manual reference counting model and is typically used
> > +//! with C types that implement reference counting (e.g., via `refcount_t` or `kref`).
> > +//!
> > +//! For Rust-managed objects, prefer using [`Arc`](crate::sync::Arc) instead.
> > +
> > +use core::{
> > + marker::PhantomData,
> > + mem::ManuallyDrop,
> > + ops::Deref,
> > + ptr::NonNull,
> > +};
> > +
> > +/// Trait for types that are _always_ reference-counted.
> > +///
> > +/// This trait allows types to define custom reference increment and decrement logic.
> > +/// It enables safe conversion from a shared reference `&T` to an owned [`ARef<T>`].
> > +///
> > +/// This is usually implemented by wrappers around C types with manual refcounting.
> > +///
> > +/// For purely Rust-managed memory, consider using [`Arc`](crate::sync::Arc) instead.
> > +///
> > +/// # Safety
> > +///
> > +/// Implementers must ensure that:
> > +///
> > +/// - Calling [`AlwaysRefCounted::inc_ref`] keeps the object alive in memory until a matching [`AlwaysRefCounted::dec_ref`] is called.
> > +/// - The object is always managed by a reference count; it must never be stack-allocated or
> > +/// otherwise untracked.
> > +/// - When the count reaches zero in [`AlwaysRefCounted::dec_ref`], the object is properly freed and no further
> > +/// access occurs.
> > +///
> > +/// Failure to follow these rules may lead to use-after-free or memory corruption.
>
> You also rephrased these docs, can you do that in a separate patch?
>
> > +
>
> Newline?
>
> ---
> Cheers,
> Benno
>
> > +pub unsafe trait AlwaysRefCounted {
> > + /// Increments the reference count on the object.
> > + fn inc_ref(&self);
> > +
> > + /// Decrements the reference count on the object.
> > + ///
> > + /// Frees the object when the count reaches zero.
> > + ///
> > + /// # Safety
> > + ///
> > + /// Callers must ensure that there was a previous matching increment to the reference count,
> > + /// and that the object is no longer used after its reference count is decremented (as it may
> > + /// result in the object being freed), unless the caller owns another increment on the refcount
> > + /// (e.g., it calls [`AlwaysRefCounted::inc_ref`] twice, then calls
> > + /// [`AlwaysRefCounted::dec_ref`] once).
> > + unsafe fn dec_ref(obj: NonNull<Self>);
> > +}
next prev parent reply other threads:[~2025-06-26 13:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 11:11 [PATCH v2 1/2] rust: move ARef and AlwaysRefCounted to sync::aref Shankari Anand
2025-06-25 11:11 ` [PATCH v2 2/2] rust: update ARef and AlwaysRefCounted call sites to import from sync::aref Shankari Anand
2025-07-02 12:24 ` kernel test robot
2025-06-25 22:29 ` [PATCH v2 1/2] rust: move ARef and AlwaysRefCounted to sync::aref Benno Lossin
2025-06-26 13:55 ` Shankari Anand [this message]
2025-07-02 11:01 ` kernel test robot
[not found] <20250625101805.645133-1-shankari.ak0208@gmail.com>
[not found] ` <CANiq72nvnqeeteLvhgf-ZfSQN4M_dKKBB41DuOKoboV5an=1Tw@mail.gmail.com>
[not found] ` <CAPRMd3ncagoKUyy=3aEZndDeVpbnrME9G7dc4jM1Vv+ArQJzXw@mail.gmail.com>
2025-06-25 10:57 ` Miguel Ojeda
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='CAPRMd3=5aMx_DmhuXxWbNodM8OV6EWkXMTByAzOSr3ESoSj_BQ@mail.gmail.com' \
--to=shankari.ak0208@gmail.com \
--cc=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=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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).