On Tue, 2026-05-26 at 22:59 -0700, Boqun Feng wrote: > 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/[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(). > > > > 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 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. But in principle you can regard my patch here to be withdrawn :) Regards P. > > Regards, > Boqun > > > Alice
