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

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Boqun Feng <boqun@kernel.org> [260211 13:00]:
> 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.

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
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?

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?

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.

Thanks,
Liam