On Sat, Jan 17, 2026 at 08:06:40AM +0800, Boqun Feng wrote: > On Fri, Jan 16, 2026 at 03:46:35PM +0000, Alice Ryhl wrote: > > I'm sending this RFC to share an experiment I'm looking at. This may let > > us replace the range allocator in Rust Binder with a maple tree. > > > > Thank you, Alice. > > > 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? 1) "relaxed atomic" does not sound like something that provides an address dependency to me. 2) How do you intend to provide mutable access? By waiting a grace period? > As for the progress of that effort, the Rcu atomic pointer is almost > ready [2], I will likely send it early next week. For the `HasRcuHead` > part, as you may be aware, I'm working on a generic `HasField` approach > to avoid duplication of `Has*` trait and macros [3], that requires some > syn adjustments from Gary and Benno, but they should be available next > cycle. I will probably send the patches for reviews before that. Once we > have that `HasRcuHead` should be easily to add. > > Given the WIP code I have, I *think* we are not that far from providing > what you need for binder. 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 synchronize_rcu() for cleanup - I need kfree_rcu(). Alice
