[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWt4muGXbe7lBmXt@google.com>
Date: Sat, 17 Jan 2026 11:55:06 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Gary Guo <gary@...yguo.net>, Miguel Ojeda <ojeda@...nel.org>,
"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>, Joel Fernandes <joelagnelf@...dia.com>,
Josh Triplett <josh@...htriplett.org>, Uladzislau Rezki <urezki@...il.com>,
Steven Rostedt <rostedt@...dmis.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang@...ux.dev>,
Andrew Ballance <andrewjballance@...il.com>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org, rcu@...r.kernel.org,
maple-tree@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH RFC 0/2] rcu box container for Rust + maple tree load_rcu
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
Powered by blists - more mailing lists