On Sat, Jan 17, 2026 at 08:11:17PM +0800, Boqun Feng wrote: [...] > > > > An RcuBox is like a Box except that it lets you obtain a &T that > > > > outlives the box by a grace period. It does not allow mutable access to > > > > > > I think the `RcuBox` can be folded into the more generic RCU pointer api > > > [1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The > > > benefits are at least 1) we use relaxed atomic read for RCU readers > > > which guarantees address dependency that RCU needs under LKMM (while in > > > the RcuBox here, we just use plain reads), 2) we also support mutable > > > access as well. > > > > 1) But mtree_load() does use rcu_dereference() to obtain the pointer?
I see, I need to change my reply to "RcuOld" below.. [...] > > > > Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather > > than an Rcu<_> under this model. Though I can't afford to pay > > I don't think so, `RcuOld` represents an unpublished object while `Rcu` > represents a published object, you can update an `Rcu` pointer to > another object, which is normally how you update with RCU. But maybe > it's easy to discuss this with updater side code in picture. > I think a more accurate reply should be `RcuOld` is still not designed for the usage of `RcuBox`. You're right that `RcuBox` is not an `Rcu<_>` since `RcuBox` don't have the atomic pointer part, instead it relies other atomic pointer operations to work (for example, the rcu_dereference() in mtree_load()). `RcuBox` represents an object pointed (and protected) by RCU. `Rcu<_>` is an atomic pointer that maintains read and update for RCU, in your usage, you don't need it because maple tree does that for you. `RcuOld<_>` works with `Rcu<_>` to provide an API for users to decide how to handle RCU reclaim. In Rcu + RcuOld design, RcuBox is just a Box because these two pointer types handle reclaim + accesses. We will need to use `Rcu` and `RcuOld` where the RCU access code is in Rust. I think there are similarities between `RcuOld` and `RcuBox`, but they are sort of designed with different usages in mind, lemme think more.. Regards, Boqun > > synchronize_rcu() for cleanup - I need kfree_rcu(). > > > > That's something we can add later, for example, we can give `Rcu` (we > can add the similar thing to `RcuOld`) a generic const like: > > struct Rcu<P, const ASYNC: u64 = 0>(..) > > where Rcu<P, 0> use synchronize_rcu() and Rcu<P, 1> use kfree_rcu() or > call_rcu() (once we have HasRcuHead support). > > Regards, > Boqun > > > Alice
