I'm sending this RFC to share an experiment I'm looking at. This may let
us replace the range allocator in Rust Binder with a maple tree.

An RcuBox is like a Box except that it lets you obtain a &T that
outlives the box by a grace period. It does not allow mutable access to
the inner value (Binder would probably use LockedBy for inner values).

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Alice Ryhl (2):
      rust: rcu: add RcuBox type
      rust: maple_tree: add load_rcu()

 rust/bindings/bindings_helper.h |   1 +
 rust/kernel/maple_tree.rs       |  52 ++++++++++++++
 rust/kernel/sync/rcu.rs         |  31 ++++++++-
 rust/kernel/sync/rcu/rcu_box.rs | 145 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 228 insertions(+), 1 deletion(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260116-rcu-box-7a8e4c9f2180

Best regards,
-- 
Alice Ryhl <aliceryhl@google.com>

On Fri, Jan 16, 2026 at 03:46:35PM +0000, Alice Ryhl wrote:
> I'm sending this RFC to share an experiment I'm looking at. This may let
> us replace the range allocator in Rust Binder with a maple tree.
> 

Thank you, Alice.

> An RcuBox is like a Box except that it lets you obtain a &T that
> outlives the box by a grace period. It does not allow mutable access to

I think the `RcuBox` can be folded into the more generic RCU pointer api
[1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The
benefits are at least 1) we use relaxed atomic read for RCU readers
which guarantees address dependency that RCU needs under LKMM (while in
the RcuBox here, we just use plain reads), 2) we also support mutable
access as well.

As for the progress of that effort, the Rcu atomic pointer is almost
ready [2], I will likely send it early next week. For the `HasRcuHead`
part, as you may be aware, I'm working on a generic `HasField` approach
to avoid duplication of `Has*` trait and macros [3], that requires some
syn adjustments from Gary and Benno, but they should be available next
cycle. I will probably send the patches for reviews before that. Once we
have that `HasRcuHead` should be easily to add.

Given the WIP code I have, I *think* we are not that far from providing
what you need for binder.

> the inner value (Binder would probably use LockedBy for inner values).
> 

[1]: https://lore.kernel.org/rust-for-linux/20250421164221.1121805-13-boqun.feng@gmail.com/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git/log/?h=rust-sync
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git/log/?h=rust-field

Regards,
Boqun

> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Alice Ryhl (2):
>       rust: rcu: add RcuBox type
>       rust: maple_tree: add load_rcu()
> 
>  rust/bindings/bindings_helper.h |   1 +
>  rust/kernel/maple_tree.rs       |  52 ++++++++++++++
>  rust/kernel/sync/rcu.rs         |  31 ++++++++-
>  rust/kernel/sync/rcu/rcu_box.rs | 145 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 228 insertions(+), 1 deletion(-)
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20260116-rcu-box-7a8e4c9f2180
> 
> Best regards,
> -- 
> Alice Ryhl <aliceryhl@google.com>
>

On Sat, Jan 17, 2026 at 08:06:40AM +0800, Boqun Feng wrote:
> On Fri, Jan 16, 2026 at 03:46:35PM +0000, Alice Ryhl wrote:
> > I'm sending this RFC to share an experiment I'm looking at. This may let
> > us replace the range allocator in Rust Binder with a maple tree.
> > 
> 
> Thank you, Alice.
> 
> > An RcuBox is like a Box except that it lets you obtain a &T that
> > outlives the box by a grace period. It does not allow mutable access to
> 
> I think the `RcuBox` can be folded into the more generic RCU pointer api
> [1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The
> benefits are at least 1) we use relaxed atomic read for RCU readers
> which guarantees address dependency that RCU needs under LKMM (while in
> the RcuBox here, we just use plain reads), 2) we also support mutable
> access as well.

1) But mtree_load() does use rcu_dereference() to obtain the pointer?
1) "relaxed atomic" does not sound like something that provides an
   address dependency to me.
2) How do you intend to provide mutable access? By waiting a grace
   period?

> As for the progress of that effort, the Rcu atomic pointer is almost
> ready [2], I will likely send it early next week. For the `HasRcuHead`
> part, as you may be aware, I'm working on a generic `HasField` approach
> to avoid duplication of `Has*` trait and macros [3], that requires some
> syn adjustments from Gary and Benno, but they should be available next
> cycle. I will probably send the patches for reviews before that. Once we
> have that `HasRcuHead` should be easily to add.
> 
> Given the WIP code I have, I *think* we are not that far from providing
> what you need for binder.

Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather
than an Rcu<_> under this model. Though I can't afford to pay
synchronize_rcu() for cleanup - I need kfree_rcu().

Alice

On Sat, Jan 17, 2026 at 11:55:06AM +0000, Alice Ryhl wrote:
> On Sat, Jan 17, 2026 at 08:06:40AM +0800, Boqun Feng wrote:
> > On Fri, Jan 16, 2026 at 03:46:35PM +0000, Alice Ryhl wrote:
> > > I'm sending this RFC to share an experiment I'm looking at. This may let
> > > us replace the range allocator in Rust Binder with a maple tree.
> > > 
> > 
> > Thank you, Alice.
> > 
> > > An RcuBox is like a Box except that it lets you obtain a &T that
> > > outlives the box by a grace period. It does not allow mutable access to
> > 
> > I think the `RcuBox` can be folded into the more generic RCU pointer api
> > [1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The
> > benefits are at least 1) we use relaxed atomic read for RCU readers
> > which guarantees address dependency that RCU needs under LKMM (while in
> > the RcuBox here, we just use plain reads), 2) we also support mutable
> > access as well.
> 
> 1) But mtree_load() does use rcu_dereference() to obtain the pointer?
> 1) "relaxed atomic" does not sound like something that provides an
>    address dependency to me.

If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
address dependency (Please see the DEPENDENCY part in
tools/memory-model/Documentation/explanation.txt).

> 2) How do you intend to provide mutable access? By waiting a grace
>    period?

Please see the {read_}copy_update() in the RCU patches that I linked.
In short, you don't wait a grace for mutable access, since in RCU,
readers don't block updaters, but instead updater will copy the object,
atomically update the pointer and then get an `RcuOld`,
which you can either synchronize_rcu() or {call,kfree}_rcu().
 
> > As for the progress of that effort, the Rcu atomic pointer is almost
> > ready [2], I will likely send it early next week. For the `HasRcuHead`
> > part, as you may be aware, I'm working on a generic `HasField` approach
> > to avoid duplication of `Has*` trait and macros [3], that requires some
> > syn adjustments from Gary and Benno, but they should be available next
> > cycle. I will probably send the patches for reviews before that. Once we
> > have that `HasRcuHead` should be easily to add.
> > 
> > Given the WIP code I have, I *think* we are not that far from providing
> > what you need for binder.
> 
> Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather
> than an Rcu<_> under this model. Though I can't afford to pay

I don't think so, `RcuOld` represents an unpublished object while `Rcu`
represents a published object, you can update an `Rcu` pointer to
another object, which is normally how you update with RCU. But maybe
it's easy to discuss this with updater side code in picture.

> synchronize_rcu() for cleanup - I need kfree_rcu().
> 

That's something we can add later, for example, we can give `Rcu` (we
can add the similar thing to `RcuOld`) a generic const like:

    struct Rcu<P, const ASYNC: u64 = 0>(..)

where Rcu<P, 0> use synchronize_rcu() and Rcu<P, 1> use kfree_rcu() or
call_rcu() (once we have HasRcuHead support).

Regards,
Boqun

> Alice

On Sat, Jan 17, 2026 at 08:11:17PM +0800, Boqun Feng wrote:
[...]
> > > > An RcuBox is like a Box except that it lets you obtain a &T that
> > > > outlives the box by a grace period. It does not allow mutable access to
> > > 
> > > I think the `RcuBox` can be folded into the more generic RCU pointer api
> > > [1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The
> > > benefits are at least 1) we use relaxed atomic read for RCU readers
> > > which guarantees address dependency that RCU needs under LKMM (while in
> > > the RcuBox here, we just use plain reads), 2) we also support mutable
> > > access as well.
> > 
> > 1) But mtree_load() does use rcu_dereference() to obtain the pointer?

I see, I need to change my reply to "RcuOld" below..

[...]

> > 
> > Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather
> > than an Rcu<_> under this model. Though I can't afford to pay
> 
> I don't think so, `RcuOld` represents an unpublished object while `Rcu`
> represents a published object, you can update an `Rcu` pointer to
> another object, which is normally how you update with RCU. But maybe
> it's easy to discuss this with updater side code in picture.
> 

I think a more accurate reply should be `RcuOld` is still not designed
for the usage of `RcuBox`. You're right that `RcuBox` is not an `Rcu<_>`
since `RcuBox` don't have the atomic pointer part, instead it relies
other atomic pointer operations to work (for example, the
rcu_dereference() in mtree_load()).

`RcuBox` represents an object pointed (and protected) by RCU.

`Rcu<_>` is an atomic pointer that maintains read and update for RCU, in
your usage, you don't need it because maple tree does that for you.

`RcuOld<_>` works with `Rcu<_>` to provide an API for users to decide
how to handle RCU reclaim. In Rcu + RcuOld design, RcuBox is just a Box
because these two pointer types handle reclaim + accesses.


We will need to use `Rcu` and `RcuOld` where the RCU access code is in
Rust.


I think there are similarities between `RcuOld` and `RcuBox`, but they
are sort of designed with different usages in mind, lemme think more..

Regards,
Boqun
 
> > synchronize_rcu() for cleanup - I need kfree_rcu().
> > 
> 
> That's something we can add later, for example, we can give `Rcu` (we
> can add the similar thing to `RcuOld`) a generic const like:
> 
>     struct Rcu<P, const ASYNC: u64 = 0>(..)
> 
> where Rcu<P, 0> use synchronize_rcu() and Rcu<P, 1> use kfree_rcu() or
> call_rcu() (once we have HasRcuHead support).
> 
> Regards,
> Boqun
> 
> > Alice

On Sat, Jan 17, 2026 at 09:11:49PM +0800, Boqun Feng wrote:
> In Rcu + RcuOld design, RcuBox is just a Box
> because these two pointer types handle reclaim + accesses.

How would that work? Dropping my RcuBox<_> must use kfree_rcu() or
synchronize_rcu() or it is unsound. So it can't just be a Box.

Alice

On Sat, Jan 17, 2026 at 01:29:25PM +0000, Alice Ryhl wrote:
> On Sat, Jan 17, 2026 at 09:11:49PM +0800, Boqun Feng wrote:
> > In Rcu + RcuOld design, RcuBox is just a Box
> > because these two pointer types handle reclaim + accesses.
> 
> How would that work? Dropping my RcuBox<_> must use kfree_rcu() or
> synchronize_rcu() or it is unsound. So it can't just be a Box.
> 

RcuOld<P: ForeignOwnable> will call synchronize_rcu() before dropping
`P`. And I think we can have an asynchronous drop pointer type like
`RcuOld<P, Async>` that requires `P` is a type like `Box<HasRcuHead>`,
and the drop of `RcuOld<Box<HasRcuHead>, Async>` would be `call_rcu()`
or `kfree_rcu()`.

Regards,
Boqun

> Alice

On Sat, Jan 17, 2026 at 10:05:18PM +0800, Boqun Feng wrote:
> On Sat, Jan 17, 2026 at 01:29:25PM +0000, Alice Ryhl wrote:
> > On Sat, Jan 17, 2026 at 09:11:49PM +0800, Boqun Feng wrote:
> > > In Rcu + RcuOld design, RcuBox is just a Box
> > > because these two pointer types handle reclaim + accesses.
> > 
> > How would that work? Dropping my RcuBox<_> must use kfree_rcu() or
> > synchronize_rcu() or it is unsound. So it can't just be a Box.
> > 
> 
> RcuOld<P: ForeignOwnable> will call synchronize_rcu() before dropping
> `P`. And I think we can have an asynchronous drop pointer type like
> `RcuOld<P, Async>` that requires `P` is a type like `Box<HasRcuHead>`,

One blocker on that is Drop impls cannot be specialized. We probably
need a different pointer type like RcuOldAsync...

Regards,
Boqun

> and the drop of `RcuOld<Box<HasRcuHead>, Async>` would be `call_rcu()`
> or `kfree_rcu()`.
> 
> Regards,
> Boqun
> 
> > Alice

On Sat Jan 17, 2026 at 3:39 PM GMT, Boqun Feng wrote:
> On Sat, Jan 17, 2026 at 10:05:18PM +0800, Boqun Feng wrote:
>> On Sat, Jan 17, 2026 at 01:29:25PM +0000, Alice Ryhl wrote:
>> > On Sat, Jan 17, 2026 at 09:11:49PM +0800, Boqun Feng wrote:
>> > > In Rcu + RcuOld design, RcuBox is just a Box
>> > > because these two pointer types handle reclaim + accesses.
>> > 
>> > How would that work? Dropping my RcuBox<_> must use kfree_rcu() or
>> > synchronize_rcu() or it is unsound. So it can't just be a Box.
>> > 
>> 
>> RcuOld<P: ForeignOwnable> will call synchronize_rcu() before dropping
>> `P`. And I think we can have an asynchronous drop pointer type like
>> `RcuOld<P, Async>` that requires `P` is a type like `Box<HasRcuHead>`,
>
> One blocker on that is Drop impls cannot be specialized. We probably
> need a different pointer type like RcuOldAsync...

I won't be too worried on this apsect, you could just branch on a const in the
drop function.

Alternatively, we can have a method like this

impl<T: HasRcuHead> RcuOld<Box<T>> {
    fn drop_async(self) {
        // do call_rcu
    }
}

Best,
Gary

On Sat, Jan 17, 2026 at 08:11:17PM +0800, Boqun Feng wrote:
> On Sat, Jan 17, 2026 at 11:55:06AM +0000, Alice Ryhl wrote:
> > On Sat, Jan 17, 2026 at 08:06:40AM +0800, Boqun Feng wrote:
> > > On Fri, Jan 16, 2026 at 03:46:35PM +0000, Alice Ryhl wrote:
> > > > I'm sending this RFC to share an experiment I'm looking at. This may let
> > > > us replace the range allocator in Rust Binder with a maple tree.
> > > > 
> > > 
> > > Thank you, Alice.
> > > 
> > > > An RcuBox is like a Box except that it lets you obtain a &T that
> > > > outlives the box by a grace period. It does not allow mutable access to
> > > 
> > > I think the `RcuBox` can be folded into the more generic RCU pointer api
> > > [1], e.g. Rcu<Box<RcuBoxInner<T>>> where RcuBoxInner<T>: HasRcuHead. The
> > > benefits are at least 1) we use relaxed atomic read for RCU readers
> > > which guarantees address dependency that RCU needs under LKMM (while in
> > > the RcuBox here, we just use plain reads), 2) we also support mutable
> > > access as well.
> > 
> > 1) But mtree_load() does use rcu_dereference() to obtain the pointer?
> > 1) "relaxed atomic" does not sound like something that provides an
> >    address dependency to me.
> 
> If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> address dependency (Please see the DEPENDENCY part in
> tools/memory-model/Documentation/explanation.txt).

You argued that we should rename READ_ONCE() to atomic load on that
other patch series because "atomic load" naming is better than what LKMM
normally uses. Fine, but relaxed atomic load is a much worse name than
READ_ONCE() if what you want to convey is "has address dependency".
That's not what "relaxed" means!

I suppose you can argue that the word "relaxed" means different things
in LKMM than it does elsewhere, but I looked over the doc you mentioned,
and there the LKMM calls said operation READ_ONCE(). The word "relaxed"
does not appear even once. If we're going to change terminology / use
new terminology, let's at least pick terminology that's not
contradictory with the rest of the world.

> > 2) How do you intend to provide mutable access? By waiting a grace
> >    period?
> 
> Please see the {read_}copy_update() in the RCU patches that I linked.
> In short, you don't wait a grace for mutable access, since in RCU,
> readers don't block updaters, but instead updater will copy the object,
> atomically update the pointer and then get an `RcuOld`,
> which you can either synchronize_rcu() or {call,kfree}_rcu().

Hm, ok. I don't really need that. What I want rcu for is the internal
maple tree data structure, so mtree_load() doesn't need to block on the
maple tree internal spinlock. The contents of the box would be protected
by a separate lock (probably via LockedBy).

> > > As for the progress of that effort, the Rcu atomic pointer is almost
> > > ready [2], I will likely send it early next week. For the `HasRcuHead`
> > > part, as you may be aware, I'm working on a generic `HasField` approach
> > > to avoid duplication of `Has*` trait and macros [3], that requires some
> > > syn adjustments from Gary and Benno, but they should be available next
> > > cycle. I will probably send the patches for reviews before that. Once we
> > > have that `HasRcuHead` should be easily to add.
> > > 
> > > Given the WIP code I have, I *think* we are not that far from providing
> > > what you need for binder.
> > 
> > Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather
> > than an Rcu<_> under this model. Though I can't afford to pay
> 
> I don't think so, `RcuOld` represents an unpublished object while `Rcu`
> represents a published object, you can update an `Rcu` pointer to
> another object, which is normally how you update with RCU. But maybe
> it's easy to discuss this with updater side code in picture.

When the RcuBox<_> is an owned value in Rust code, it's unpublished.
It's only published while it's foreign-owned by the maple tree.

Alice

On Sat, Jan 17, 2026 at 01:12:08PM +0000, Alice Ryhl wrote:
[...]
> > > 1) "relaxed atomic" does not sound like something that provides an
> > >    address dependency to me.
> > 
> > If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> > as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> > address dependency (Please see the DEPENDENCY part in
> > tools/memory-model/Documentation/explanation.txt).
> 
> You argued that we should rename READ_ONCE() to atomic load on that
> other patch series because "atomic load" naming is better than what LKMM
> normally uses. Fine, but relaxed atomic load is a much worse name than

To be clear, in that series, my argument was not about naming, it's
about READ_ONCE() being more powerful than atomic load (no, not because
of address dependency, they are the same on that, it's because of the
behaviors of them regarding a current access on the same memory
location), and we want user to specify the intention more clearly.

> READ_ONCE() if what you want to convey is "has address dependency".
> That's not what "relaxed" means!
> 

Also note that my previous reply was explaining why we don't need to
call rcu_dereference() from Rust, because implementation-wise the
LKMM relaxed atomic load provides the address dependency. Depending on
what we want to do, we can limit this address dependency only to
rcu_dereference() and make it a special case, this means we disallow the
address dependency provided by the "relaxed" in normal cases. Or we can
add a Consume ordering (a type alias to Relaxed) that makes user to
explicitly use it when they rely on the address dependency. I think
either would resolve your concern about the name of "relaxed".

> I suppose you can argue that the word "relaxed" means different things
> in LKMM than it does elsewhere, but I looked over the doc you mentioned,
> and there the LKMM calls said operation READ_ONCE(). The word "relaxed"
> does not appear even once. If we're going to change terminology / use
> new terminology, let's at least pick terminology that's not
> contradictory with the rest of the world.
> 
> > > 2) How do you intend to provide mutable access? By waiting a grace
> > >    period?
> > 
> > Please see the {read_}copy_update() in the RCU patches that I linked.
> > In short, you don't wait a grace for mutable access, since in RCU,
> > readers don't block updaters, but instead updater will copy the object,
> > atomically update the pointer and then get an `RcuOld`,
> > which you can either synchronize_rcu() or {call,kfree}_rcu().
> 
> Hm, ok. I don't really need that. What I want rcu for is the internal
> maple tree data structure, so mtree_load() doesn't need to block on the
> maple tree internal spinlock. The contents of the box would be protected
> by a separate lock (probably via LockedBy).
> 

You mean after `load_rcu()`, we could access mutably by a lock? You need
to hold that lock and the rcu_read_lock() while mutably accessing the
return of `load_rcu()`, right? That is basically using RCU as a proof
for existence.

Regards,
Boqun

On Sat, Jan 17, 2026 at 10:00:19PM +0800, Boqun Feng wrote:
> On Sat, Jan 17, 2026 at 01:12:08PM +0000, Alice Ryhl wrote:
> [...]
> > > > 1) "relaxed atomic" does not sound like something that provides an
> > > >    address dependency to me.
> > > 
> > > If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> > > as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> > > address dependency (Please see the DEPENDENCY part in
> > > tools/memory-model/Documentation/explanation.txt).
> > 
> > You argued that we should rename READ_ONCE() to atomic load on that
> > other patch series because "atomic load" naming is better than what LKMM
> > normally uses. Fine, but relaxed atomic load is a much worse name than
> 
> To be clear, in that series, my argument was not about naming, it's
> about READ_ONCE() being more powerful than atomic load (no, not because
> of address dependency, they are the same on that, it's because of the
> behaviors of them regarding a current access on the same memory
> location), and we want user to specify the intention more clearly.

Expressing intent more clearly is fine with me. I still think it's weird
for us to not have READ_ONCE() when it's a primitive operation of our
memory model, though.

And I also think we should consider using an implementation along the
lines of what I shared for our atomic_load() or READ_ONCE() or whatever
you wish to call it. The perf impact of helpers makes me sad.

> > READ_ONCE() if what you want to convey is "has address dependency".
> > That's not what "relaxed" means!
> > 
> 
> Also note that my previous reply was explaining why we don't need to
> call rcu_dereference() from Rust, because implementation-wise the
> LKMM relaxed atomic load provides the address dependency. Depending on
> what we want to do, we can limit this address dependency only to
> rcu_dereference() and make it a special case, this means we disallow the
> address dependency provided by the "relaxed" in normal cases. Or we can
> add a Consume ordering (a type alias to Relaxed) that makes user to
> explicitly use it when they rely on the address dependency. I think
> either would resolve your concern about the name of "relaxed".

Yes, I suppose that would resolve my concern about the name.

Well, I do have one partial concern there, which is that the wrong name
will show up in stack traces as long as helpers are used.

> > I suppose you can argue that the word "relaxed" means different things
> > in LKMM than it does elsewhere, but I looked over the doc you mentioned,
> > and there the LKMM calls said operation READ_ONCE(). The word "relaxed"
> > does not appear even once. If we're going to change terminology / use
> > new terminology, let's at least pick terminology that's not
> > contradictory with the rest of the world.
> > 
> > > > 2) How do you intend to provide mutable access? By waiting a grace
> > > >    period?
> > > 
> > > Please see the {read_}copy_update() in the RCU patches that I linked.
> > > In short, you don't wait a grace for mutable access, since in RCU,
> > > readers don't block updaters, but instead updater will copy the object,
> > > atomically update the pointer and then get an `RcuOld`,
> > > which you can either synchronize_rcu() or {call,kfree}_rcu().
> > 
> > Hm, ok. I don't really need that. What I want rcu for is the internal
> > maple tree data structure, so mtree_load() doesn't need to block on the
> > maple tree internal spinlock. The contents of the box would be protected
> > by a separate lock (probably via LockedBy).
> > 
> 
> You mean after `load_rcu()`, we could access mutably by a lock? You need
> to hold that lock and the rcu_read_lock() while mutably accessing the
> return of `load_rcu()`, right? That is basically using RCU as a proof
> for existence.

Yeah, that's right.

Alice

On Wed, Jan 21, 2026 at 12:10:54PM +0000, Alice Ryhl wrote:
> On Sat, Jan 17, 2026 at 10:00:19PM +0800, Boqun Feng wrote:
> > On Sat, Jan 17, 2026 at 01:12:08PM +0000, Alice Ryhl wrote:
> > [...]
> > > > > 1) "relaxed atomic" does not sound like something that provides an
> > > > >    address dependency to me.
> > > > 
> > > > If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> > > > as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> > > > address dependency (Please see the DEPENDENCY part in
> > > > tools/memory-model/Documentation/explanation.txt).
> > > 
> > > You argued that we should rename READ_ONCE() to atomic load on that
> > > other patch series because "atomic load" naming is better than what LKMM
> > > normally uses. Fine, but relaxed atomic load is a much worse name than
> > 
> > To be clear, in that series, my argument was not about naming, it's
> > about READ_ONCE() being more powerful than atomic load (no, not because
> > of address dependency, they are the same on that, it's because of the
> > behaviors of them regarding a current access on the same memory
> > location), and we want user to specify the intention more clearly.
> 
> Expressing intent more clearly is fine with me. I still think it's weird
> for us to not have READ_ONCE() when it's a primitive operation of our
> memory model, though.
> 

But in our memory model, it's exact the same as atomic_read() (see
tools/memory-model/linux-kernel.def and search for "atomic_read"), so
why do we want to have both? ;-)

> And I also think we should consider using an implementation along the
> lines of what I shared for our atomic_load() or READ_ONCE() or whatever
> you wish to call it. The perf impact of helpers makes me sad.
> 

I'm not totally against that, it'll actually help Atomic as well, I also
hope that we can use `asm!()` to implement the cases where
`{read,write}_volatile()` cannot cover. However currently I would rely
on helper inlining to resolve this to avoid duplicate implementations.

> > > READ_ONCE() if what you want to convey is "has address dependency".
> > > That's not what "relaxed" means!
> > > 
> > 
> > Also note that my previous reply was explaining why we don't need to
> > call rcu_dereference() from Rust, because implementation-wise the
> > LKMM relaxed atomic load provides the address dependency. Depending on
> > what we want to do, we can limit this address dependency only to
> > rcu_dereference() and make it a special case, this means we disallow the
> > address dependency provided by the "relaxed" in normal cases. Or we can
> > add a Consume ordering (a type alias to Relaxed) that makes user to
> > explicitly use it when they rely on the address dependency. I think
> > either would resolve your concern about the name of "relaxed".
> 
> Yes, I suppose that would resolve my concern about the name.
> 
> Well, I do have one partial concern there, which is that the wrong name
> will show up in stack traces as long as helpers are used.
> 

I think it won't be a problem since in LKMM, atomic_read() and
READ_ONCE() are identical.

Regards,
Boqun

> > > I suppose you can argue that the word "relaxed" means different things
> > > in LKMM than it does elsewhere, but I looked over the doc you mentioned,
> > > and there the LKMM calls said operation READ_ONCE(). The word "relaxed"
> > > does not appear even once. If we're going to change terminology / use
> > > new terminology, let's at least pick terminology that's not
> > > contradictory with the rest of the world.
> > > 
[...]

On Wed, Jan 21, 2026 at 09:14:05PM +0800, Boqun Feng wrote:
> On Wed, Jan 21, 2026 at 12:10:54PM +0000, Alice Ryhl wrote:
> > On Sat, Jan 17, 2026 at 10:00:19PM +0800, Boqun Feng wrote:
> > > On Sat, Jan 17, 2026 at 01:12:08PM +0000, Alice Ryhl wrote:
> > > [...]
> > > > > > 1) "relaxed atomic" does not sound like something that provides an
> > > > > >    address dependency to me.
> > > > > 
> > > > > If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> > > > > as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> > > > > address dependency (Please see the DEPENDENCY part in
> > > > > tools/memory-model/Documentation/explanation.txt).
> > > > 
> > > > You argued that we should rename READ_ONCE() to atomic load on that
> > > > other patch series because "atomic load" naming is better than what LKMM
> > > > normally uses. Fine, but relaxed atomic load is a much worse name than
> > > 
> > > To be clear, in that series, my argument was not about naming, it's
> > > about READ_ONCE() being more powerful than atomic load (no, not because
> > > of address dependency, they are the same on that, it's because of the
> > > behaviors of them regarding a current access on the same memory
> > > location), and we want user to specify the intention more clearly.
> > 
> > Expressing intent more clearly is fine with me. I still think it's weird
> > for us to not have READ_ONCE() when it's a primitive operation of our
> > memory model, though.
> > 
> 
> But in our memory model, it's exact the same as atomic_read() (see
> tools/memory-model/linux-kernel.def and search for "atomic_read"), so
> why do we want to have both? ;-)

I've been saying Rust should have both because I've been repeatedly told
that they are different. If READ_ONCE() and atomic_load() are the same,
then I retract my concern.

> > And I also think we should consider using an implementation along the
> > lines of what I shared for our atomic_load() or READ_ONCE() or whatever
> > you wish to call it. The perf impact of helpers makes me sad.
> > 
> 
> I'm not totally against that, it'll actually help Atomic as well, I also
> hope that we can use `asm!()` to implement the cases where
> `{read,write}_volatile()` cannot cover. However currently I would rely
> on helper inlining to resolve this to avoid duplicate implementations.

I'm in favor of using helpers to begin with. I think it's probably worth
to do atomic_load() before we do the other ops, since it's so much
simpler to implement that particular operation than the ones using asm.

Alice

On Wed, Jan 21, 2026 at 01:21:46PM +0000, Alice Ryhl wrote:
> On Wed, Jan 21, 2026 at 09:14:05PM +0800, Boqun Feng wrote:
> > On Wed, Jan 21, 2026 at 12:10:54PM +0000, Alice Ryhl wrote:
> > > On Sat, Jan 17, 2026 at 10:00:19PM +0800, Boqun Feng wrote:
> > > > On Sat, Jan 17, 2026 at 01:12:08PM +0000, Alice Ryhl wrote:
> > > > [...]
> > > > > > > 1) "relaxed atomic" does not sound like something that provides an
> > > > > > >    address dependency to me.
> > > > > > 
> > > > > > If you look at rcu_dereference(), it's a READ_ONCE(), which is the same
> > > > > > as a relaxed atomic load, and yes in LKMM, relaxed atomic load provides
> > > > > > address dependency (Please see the DEPENDENCY part in
> > > > > > tools/memory-model/Documentation/explanation.txt).
> > > > > 
> > > > > You argued that we should rename READ_ONCE() to atomic load on that
> > > > > other patch series because "atomic load" naming is better than what LKMM
> > > > > normally uses. Fine, but relaxed atomic load is a much worse name than
> > > > 
> > > > To be clear, in that series, my argument was not about naming, it's
> > > > about READ_ONCE() being more powerful than atomic load (no, not because
> > > > of address dependency, they are the same on that, it's because of the
> > > > behaviors of them regarding a current access on the same memory
> > > > location), and we want user to specify the intention more clearly.
> > > 
> > > Expressing intent more clearly is fine with me. I still think it's weird
> > > for us to not have READ_ONCE() when it's a primitive operation of our
> > > memory model, though.
> > > 
> > 
> > But in our memory model, it's exact the same as atomic_read() (see
> > tools/memory-model/linux-kernel.def and search for "atomic_read"), so
> > why do we want to have both? ;-)
> 
> I've been saying Rust should have both because I've been repeatedly told
> that they are different. If READ_ONCE() and atomic_load() are the same,
> then I retract my concern.

I confess some bemusement on the allergy to READ_ONCE() and WRITE_ONCE().
However, we have a similar thing within the Linux kernel.  READ_ONCE()
is the same as atomic_read() from am memory-ordering perspective,
and WRITE_ONCE() is the same as atomic_set() from a memory-ordering
perspective.  The difference is typing.  READ_ONCE() and WRITE_ONCE()
will eat anything, but atomic_read() and atomic_set() insist on pointers
to atomic_t.  There is also atomic_long_t and atomic64_t, just in case
you want more API members.  ;-)

							Thanx, Paul

> > > And I also think we should consider using an implementation along the
> > > lines of what I shared for our atomic_load() or READ_ONCE() or whatever
> > > you wish to call it. The perf impact of helpers makes me sad.
> > > 
> > 
> > I'm not totally against that, it'll actually help Atomic as well, I also
> > hope that we can use `asm!()` to implement the cases where
> > `{read,write}_volatile()` cannot cover. However currently I would rely
> > on helper inlining to resolve this to avoid duplicate implementations.
> 
> I'm in favor of using helpers to begin with. I think it's probably worth
> to do atomic_load() before we do the other ops, since it's so much
> simpler to implement that particular operation than the ones using asm.
> 
> Alice