On Fri, Jun 05, 2026 at 02:04:08PM +0000, Alice Ryhl wrote:
> On Fri, Jun 05, 2026 at 06:35:41AM -0700, Boqun Feng wrote:
> > The current RcuBox will call the `drop()` function after a grace period
> > inside an RCU callback. This suffices for maintaining a RCU-protected
> > object:
> > 
> >   RcuBox::drop():
> >     call_rcu(
> >       |..| { // <- call back after one grace period.
> >         T::drop(); // <- call the destructor of the inner object.
> >       }
> >     )
> > 
> > However, to support a different RCU usage pattern as below we need to
> > extend RcuBox:
> > 
> > 1. clean up the object, and unshare it from future RCU readers.
> > 2. wait for an RCU grace period.
> > 3. no other RCU readers, we can free the memory.
> > 
> > An `RcuFreeBox<T: RcuFreeSafe>` is introduced to provide support for
> > this:
> > 
> >   RcuFreeBox::drop():
> >     T::drop_before_gp(); // clean up and ushare.
> >     kfree_call_rcu(..);  // free it after one grace period.
> > 
> > Signed-off-by: Boqun Feng <[email protected]>
> > ---
> >  rust/kernel/sync/rcu.rs         | 31 +++++++++++++++
> >  rust/kernel/sync/rcu/rcu_box.rs | 68 +++++++++++++++++++++++++++++++--
> >  2 files changed, 95 insertions(+), 4 deletions(-)
> > 
> > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> > index 7da6b8d22277..7c26591bb318 100644
> > --- a/rust/kernel/sync/rcu.rs
> > +++ b/rust/kernel/sync/rcu.rs
> > @@ -4,6 +4,8 @@
> >  //!
> >  //! C header: 
> > [`include/linux/rcupdate.h`](srctree/include/linux/rcupdate.h)
> >  
> > +use core::pin::Pin;
> > +
> >  use crate::{
> >      bindings,
> >      types::{
> > @@ -82,3 +84,32 @@ pub trait ForeignOwnableRcu: ForeignOwnable {
> >      /// [`from_foreign`]: ForeignOwnable::from_foreign
> >      unsafe fn rcu_borrow<'a>(ptr: *mut ffi::c_void) -> 
> > Self::RcuBorrowed<'a>;
> >  }
> > +
> > +/// Declares a struct is safe to free after a grace period if all readers 
> > are guarded by RCU.
> > +///
> > +/// # Safety
> > +///
> > +/// Implementation must guarantee `drop_before_gp()` makes sure no future 
> > RCU reader will access
> > +/// any part of [`Self`], as a result, after `drop_before_gp()` return + 
> > one grace period, no RCU
> > +/// reader will be on the object, and it's safe to free it.
> > +///
> > +/// Notes for implementators: implementing this trait in general requires 
> > `Self` being a
> > +/// [`UnsafePinned`], i.e. a `&mut Self` is not a noalias reference if 
> > `Self` has non-trivial
> > +/// `drop()` function.
> > +pub unsafe trait RcuFreeSafe {
> > +    fn drop_before_gp(self: Pin<&mut Self>);
> > +}
> 
> Should this have an associated type for the rcu-safe view?
> 
> pub unsafe trait RcuFreeSafe {
>     type RcuView<'a>;
> 
>     /// Access this value in a manner that is safe after
>     /// `drop_before_gp` for one grace period.
>     fn rcu_view<'a>(self: Pin<&'a Self>, _rcu: &'a RcuGuard) -> 
> Self::RcuView<'a>;
> 
>     /// Drop this value in a manner where it may still be accessed via
>     /// `rcu_view` for one grace period.
>     ///
>     /// # Safety
>     ///
>     /// All other accesses to this value must happen before the call to this
>     /// method, except for accesses using `rcu_view`.
>     fn drop_before_gp(self: Pin<&mut Self>);
> }
> 
> The idea being that once you call `drop_before_gp()`, the value
> immediately becomes unusable as the type itself, but you can still use
> it via `rcu_view`. The `RcuView` type can then be a type that has a
> subset of the type's methods that is safe to use for one grace period
> after `drop_before_gp`.
> 
> If you define the trait like this, then PollCondVar becomes RcuFreeSafe.
> It can't be RcuFreeSafe today because you must not create new waiters after
> `drop_before_gp()` is called. With this modified trait, it can simply
> not provide methods for registering new waiters from the RcuView type.
> 

Good point! But I guess I could keep RcuFreeSafe as it is but remove the
`RcuFreeSafe::with_rcu()`, and this should be sufficient for
PollCondVar. I do want to wait for a meaningful usage of `rcu_view()` to
add that, but I think your idea of that is great. Or maybe you have a
potential usage in mind?

Regards,
Boqun

> Alice

Reply via email to