linux-kernel - Re: [PATCH v3 05/12] rust: xarray: use `xas_load` instead of `xa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ-ks9knC3pKpiMaG6f3C1Kr6su9p26hM7YvVMzsVwYVHGtm2Q@mail.gmail.com>
Date: Tue, 10 Feb 2026 16:22:33 -0500
From: Tamir Duberstein <tamird@...nel.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.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>, Alice Ryhl <aliceryhl@...gle.com>, 
	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 Tue, Feb 10, 2026 at 12:59 PM Liam R. Howlett
<Liam.Howlett@...cle.com> wrote:
>
> * Tamir Duberstein <tamird@...nel.org> [260210 19:54]:
> > On Tue, Feb 10, 2026 at 10:16 AM Liam R. Howlett
> > <Liam.Howlett@...cle.com> wrote:
> > >
> > > * Andreas Hindborg <a.hindborg@...nel.org> [260209 14:39]:
> > > > Replace the call to `xa_load` with `xas_load` in `Guard::load`. The
> > > > `xa_load` function takes the RCU lock internally, which we do not need,
> > > > since the `Guard` already holds an exclusive lock on the `XArray`. The
> > > > `xas_load` function operates on `xa_state` and assumes the required locks
> > > > are already held.
> > > >
> > > > This change also removes the `#[expect(dead_code)]` annotation from
> > > > `XArrayState` and its constructor, as they are now in use.
> > >
> > > I don't understand the locking here.
> > >
> > > You are saying that, since you hold the xarray write lock, you won't be
> > > taking the rcu read lock, but then you change the api of load?  That
> > > seems wrong to me.
> >
> > This patch doesn't change the API of load. Andreas is saying that the
> > type system already requires the caller to hold the xarray spin lock
> > when load is called, meaning acquiring the RCU lock isn't necessary.
>
> What I mean is that the API can no longer be called when holding the RCU
> read lock.  You seem to imply this is already the case though.
>
> >
> > >
> > > Any readers of the api that calls load will now need to hold the rcu
> > > read lock externally.  If you're doing this, then you should indicate
> > > that is necessary in the function name, like the C side does.  Otherwise
> > > you are limiting the users to the advanced API, aren't you?
> >
> > The existing API already requires users to hold the xarray lock.
> >
> > >
> > > Or are you saying that xarray can only be used if you hold the exclusive
> > > lock, which is now a read and write lock?
> >
> > Yes - except for the word "now"; I'm not sure what you mean by it.
>
> I'm trying to understand the locking on the rust side.
>
> I think you answered it by telling me that all readers and writers use
> the spinlock.

Indeed. The current API doesn't expose load on the xarray at all; load
is only available on the "guard" type. An instance of "guard" can
exist only when the lock is held. The lock is unlocked when the guard
is dropped.

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


>
> Thanks,
> Liam