Re: [PATCH v1] rust: rcu: Add abstraction for call_rcu()

[Alice Ryhl <aliceryhl@google.com>]

On Tue, May 26, 2026 at 09:10:07AM -0700, Boqun Feng wrote:
> On Thu, May 21, 2026 at 09:25:28AM +0200, Philipp Stanner wrote:
> > [+cc Boris]
> > 
> > On Wed, 2026-05-20 at 06:59 -0700, Boqun Feng wrote:
> > > Hi Philipp,
> > 
> > Hi Boqun; hope you're doing well
> > 
> > > 
> > > On Wed, May 20, 2026 at 03:17:26PM +0200, Philipp Stanner wrote:
> > > > call_rcu() can be expected to be needed by a great variety of users.
> > > > This functionality is almost always used for deallocating resources
> > > > after all accessors are gone. Hence, it appears reasonable to implement
> > > > the abstractions in such a way that the user merely passes data, which
> > > > is later (after a grace period) dropped.
> > > > 
> > > > In the rare cases where the user needs special action to take place,
> > > > this could be achieved through implementing a custom drop() method.
> > > > 
> > > > Implement a first minimal abstraction for call_rcu().
> > > > 
> > > 
> > > Thanks for the patch! Do you have have any reference usage of this new
> > > API, maybe contains how RCU readers will read the data?
> > 
> > Read the data? This design does not intend to have any readers.
> > 
> 
> Please understand that from the perspective of an RCU maintainer, I
> would like to examine how the current design would work with a more
> general case, otherwise it's going to be a maintenance nightmare.
> 
> > I want it as some sort of trash-bin container that does nothing but
> > defer a drop(). Intended user will be this section here:
> > 
> > https://gitlab.freedesktop.org/pstanner/linux-drm-work/-/merge_requests/1/diffs#5ef8add7e1b3375ce9a0b47595b531244bf98dce_0_611
> > 
> 
> The fact that you need a "defer" means that there are readers, right?
> 
> You don't need to worry about here because the readers are in the
> callback of fences.
> 
> > 
> > > 
> > > Compared to Alice's RcuBox proposal:
> > > 
> > > 	https://lore.kernel.org/rust-for-linux/20260116-rcu-box-v1-1-38ebfbcd53f0@google.com/
> > > 
> > > I do have a design question: is support data type like Arc<CallBack<T>>
> > > or Pin<VBox<Callback<T>> in the plan of this API? If so, how would that
> > > be like? A separate new() and submit() function or a separate data type?
> > 
> > I wasn't aware of Alice's proposal. Let me try whether I can make it
> > work for my purposes.
> > 
> > The idea behind my code here would be to have some minimalist RCU
> > wrapper that merely defers dropping data. So it's a fire-and-forget
> > mechanism that would not support Arc: take over ownership of the data,
> > have it be unaccessible, and drop it after a grace period.
> > 
> 
> Maybe then name this data structure `RcuDeferDropBox<T>` or something?
> Because if the design goal is not to support a general RCU usage (with
> readers), than it probably shouldn't take the rcu::Callback name.
> 
> Or maybe keep the `Callback<T>`, but only implement `new()` (with a
> return type as `impl PinInit<Callback<T>>` and the rcu_head accessor of
> it. Then based on it you can implement the `RcuDeferDropBox<T>`, in this
> way, we could both support your usage and move towards a full-featured
> RCU implementation. Thoughts?
> 
> Plus, I think Alice's patch here [1] would also benefit from having a
> basic rcu::Callback (to replace `PollCondVarBoxInner`).
> 
> [1]: https://lore.kernel.org/rust-for-linux/20260523-upgrade-poll-v4-1-f5b4c747eac2@google.com/

My patch specifically uses kvfree_call_rcu(), which I think is important
that it keeps using over call_rcu().

Alice