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

[Boqun Feng <boqun@kernel.org>]

On Wed, May 27, 2026 at 05:52:21AM +0000, Alice Ryhl wrote:
> 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().
> 

Of course, but note that using call_rcu() for your case was not my
suggestion. We can reuse a general `Callback<T>` which is not tied to
call_rcu() or kvfree_call_rcu() to represent a container type with a
rcu_head for both cases (your and Philipp's).

Regards,
Boqun

> Alice