Re: [PATCH v3 05/12] rust: xarray: use `xas_load` instead of `xa_load` in `Guard::load`

[Boqun Feng <boqun@kernel.org>]

On Wed, Feb 11, 2026 at 09:32:36AM -0500, Liam R. Howlett wrote:
> * Alice Ryhl <aliceryhl@google.com> [260210 16:34]:
> > On Tue, Feb 10, 2026 at 10:23 PM Tamir Duberstein <tamird@kernel.org> wrote:
> > >
> > > On Tue, Feb 10, 2026 at 12:59 PM Liam R. Howlett
> > > <Liam.Howlett@oracle.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.

> > 
> 
> 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().

Regards,
Boqun

> At least on the maple tree side, we have both interfaces and users for
> both.  I just found the change to remove the rcu safety odd because I
> assumed both are needed.
> 
> Thanks,
> Liam