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

[Boqun Feng <boqun@kernel.org>]

On Wed, May 27, 2026 at 08:31:44AM +0200, Philipp Stanner wrote:
[..]
> > > > > 
> > > > > > 
> > > > > > 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).
> 
> I have given Alice's code a spin and concluded that it would be fully
> usable for my intended use-case. The trick would then be to force users
> of my API to pass their data in an RcuBox, which Rust can certainly

Note that we can extend RcuBox to implement `InPlaceInit` similar as a
normal Box, that way you can ask user to pass the `impl PinInit<T>`
instead of the data.

> enforce. Has the great advantage of me not having to allocate again
> just to drop something, so this is a far cleaner design.
> 
> From my side, only minor details would remain open regarding Alice's
> draft, like Boqun's question about how to implement VBox maybe.
> 

I think we can make RcuBox generic over Allocator, i.e.
`RcuBox<T, A: Allocator>` then we should be able to support vmalloc as
well.

Regards,
Boqun

> But in principle you can regard my patch here to be withdrawn :)
> 
> Regards
> P.
> 
> > 
> > Regards,
> > Boqun
> > 
> > > Alice
>