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

From: Liam R. Howlett

Date: Wed Feb 11 2026 - 09:34:39 EST


* Alice Ryhl <aliceryhl@xxxxxxxxxx> [260210 16:34]:
> On Tue, Feb 10, 2026 at 10:23 PM Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
> >
> > On Tue, Feb 10, 2026 at 12:59 PM Liam R. Howlett
> > <Liam.Howlett@xxxxxxxxxx> 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
> > 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@xxxxxxxxxx/
>

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.

Or at least name the load() function to indicate which is implemented
today?

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