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/[email protected]/ > > > > > > 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/[email protected]/
My patch specifically uses kvfree_call_rcu(), which I think is important that it keeps using over call_rcu(). Alice
