Message-ID: <aYzcdqiNMtCSOlxA@tardis.local>
Date: Wed, 11 Feb 2026 11:45:58 -0800
From: Boqun Feng <boqun@...nel.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Tamir Duberstein <tamird@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Tamir Duberstein <tamird@...il.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...two.org>,
	David Rientjes <rientjes@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Harry Yoo <harry.yoo@...cle.com>,
	Daniel Gomez <da.gomez@...nel.org>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3 05/12] rust: xarray: use `xas_load` instead of
 `xa_load` in `Guard::load`

On Wed, Feb 11, 2026 at 01:55:43PM -0500, Liam R. Howlett wrote:
> * Boqun Feng <boqun@...nel.org> [260211 13:00]:
> > On Wed, Feb 11, 2026 at 09:32:36AM -0500, Liam R. Howlett wrote:
> > > * Alice Ryhl <aliceryhl@...gle.com> [260210 16:34]:
> > > > On Tue, Feb 10, 2026 at 10:23 PM Tamir Duberstein <tamird@...nel.org> wrote:
> > > > >
> > > > > On Tue, Feb 10, 2026 at 12:59 PM Liam R. Howlett
> > > > > <Liam.Howlett@...cle.com> wrote:
> > > > > > Is this a temporary limitation?
> > > > >
> > > > > Maybe? I don't think RfL has good abstractions for RCU yet. For
> > > > > example, exposing load directly on the xarray using xa_load would
> > > > > require a way to guarantee that the returned pointer's target isn't
> > 
> > Well, if we only return a pointer, we don't need to guarantee that,
> > right? Because it's up to the user to provide that guarantee. So we
> > could have XArray::load() (not Guard::load()) that just calls xa_load().
> > Also see below.
> > 
> > > > > being concurrently mutated (e.g. under the xarray lock). I'm not aware
> > > > > of anyone asking for this, though.
> > > > 
> > > > It's relatively easy to add an rcu-backed load using the RCU
> > > > abstractions we have today. I already shared an RFC containing such a
> > > > method for the maple tree, and it would not be much different for
> > > > xarray.
> > > > https://lore.kernel.org/all/20260116-rcu-box-v1-0-38ebfbcd53f0@google.com/
> > 
> > I need to point out a difference between xas_load() and Alice's usage
> > (also what Tamir mentioned above) there, what Alice needs (at least from
> > her patchset) is the existence of the object is protected by RCU, i.e.
> > if there is someone else dropping the object, a RCU read lock would
> > still guarantee the access to the object is valid.
> > 
> > However, the internal RCU usage of both xarray and maple tree is to
> > protect the *internal* data structure if I'm not missing anything, i.e.
> > an writer may change the array or the tree while a reader is reading,
> > the internal structure itself is still consistent and valid. But the
> > nothing guarantees the object you read is still valid. For example, you
> > can have an xa_erase() racing with an xa_load():
> > 
> > 	<writer>			<reader>
> > 	ptr = xa_erase(xa, idx);
> > 					ptr = xa_load(xa, idx);
> > 	reclaim(ptr);
> > 					use(ptr); // <- object may be gone
> > 
> > the users of xarray needs to use other mechanism to guarantee the
> > existence of the object.
> > 
> > In Alice's case, she in fact used an RCU read side critical section with
> > a larger scope to protect the object as well, which is definitely nice
> > to have, but not only way of using maple/xarray.
> 
> The lock surrounding the ptr is only useful if your ptr is rcu
> protected, which isn't always the case.  So having the rcu read side

Right, so what Alice had in her patchset linked was introducing an RCU
protected type wrapper for an object, so that is particularly for the
case where the object is under RCU protection. (I would like to arrange
the implementation and API in a slight different way for that patchset,
but the idea is solid)

> critical section extended to the life of the ptr means you've extended
> the rcu window for no reason when the ptr is protected in another way.
> This may perform poorly, depending on the situation.
> 
> > 
> > > > 
> > > 
> > > It would probably be worth having two loads then, one that does
> > > rcu_read_lock()/unlock() and one for writer/advanced users like we have
> > > on the C side of things.
> > > 
> > 
> > Agreed. But we may need more ;-)
> > 
> > Here IIUC that Andreas does is adding a `load()` for `Guard` of
> > `XArray`, which is the load for a writer and most certainly you won't
> > need to take an RCU read lock for that. The load of a reader can be
> > added as I suggested above (similar as your "rcu_read_lock()/unlock()"
> > suggestion above), but no object existence guarantee. We likely
> > need a third API that can provide the object existence similar to what
> > Alice had in maple tree.
> > 
> > > Or at least name the load() function to indicate which is implemented
> > > today?
> > > 
> > 
> > It's a namespace thing ;-) , the function in this patch is
> > kernel::xarray::Guard::load(), and as I suggest here
> > kernel::xarray::XArray::load() should be the same as xa_load().
> 
> Ah, okay.. this might be hard to follow in code, but I guess the
> compiler will catch the wrong user.  That is, Guard::load() would not be
> written out, we'd just see array.load() in both cases?
> 

For `Guard::load()` case, you will need to write:

	let ptr = xa.lock().load();

or

	let guard = xa.lock();
	let ptr = guard.load();

for `XArray::load()` case, you will need to write:

	let ptr = xa.load();

> It's also more confusing with the borrowck false positive issue in play.
> That is, using Guard::load() will do more work than necessary, I believe?
> 

I'm not following that thread closely, but seem so.

> It is odd that only one of these exist, especially considering we have
> users for both on the C side.  I guess the other one will be added once
> it's needed.
> 

Yeah, this is the place where I don't agree with the "you must have a
user to upstream an API" rule ;-) A reader's `load()`, even with no
user, would completes the concept of what an XArrary is.

Regards,
Boqun

> Thanks,
> Liam

Powered by blists - more mailing lists