Re: [PATCH v1 1/2] rust: Add support for calling a function exactly once

Boqun Feng
2025-11-12T01:30:33Z

On Wed, Nov 12, 2025 at 06:43:49AM +0900, FUJITA Tomonori wrote:
> On Mon, 10 Nov 2025 21:17:08 -0800
> Boqun Feng <boqun.feng@gmail.com> wrote:
>
> > On Tue, Nov 11, 2025 at 12:09:49PM +0900, FUJITA Tomonori wrote:
> >> On Mon, 10 Nov 2025 08:14:56 -0800
> >> Boqun Feng <boqun.feng@gmail.com> wrote:
> >>
> >> > On Mon, Nov 10, 2025 at 06:21:50PM +0900, FUJITA Tomonori wrote:
> >> >> On Fri, 7 Nov 2025 09:03:01 +0000
> >> >> Alice Ryhl <aliceryhl@google.com> wrote:
> >> >>
> >> >> >> That's my point (and probably also Andreas' point), we already has the
> >> >> >> type `SetOnce` to do this, no need for a `OnceLite` type if not
> >> >> >> necessary, and the fact that it can be zero'd by debugfs doesn't change
> >> >> >> it as I explained above.
> >> >> >
> >> >> > The SetOnce type doesn't do the same thing as OnceLite. SetOnce has
> >> >> > three different states, but OnceLite only needs two. I don't think we
> >> >> > should be reusing SetOnce here.
> >> >
> >> > I mean 3 states should cover 2 states, right? In this case we only need
> >> > to support SetOnce<()>, so I think it's fine, see below:
> >>
> >> Yeah, that would remove access to the value member, but I think that
> >> init member could still be accessed in an unintended way.
> >>
> >
> > What an unintended way you mean? Do you have an example?
>
> From my understanding, the init member of SetOnce is designed to be
> accessed by using atomic operations, only through its methods. If we
> use SetOnce for OnceLite, however, the init member would be written
> using non-atomic operations, which is what I referred to as the
> "unintended way" since I don't believe Andreas intended it to be
> modified in that manner; i.e., not through its methods or by
> non-atomic operations.
>

Ok, the "non-atomic operations" seems to be a distraction for me to see
the real problem ;-) Let's clear things out a bit.

First of all, data races are not allowed in kernel, but kernel has
special rules about data races, namely, a few operation should be
treated as "per-byte atomics" so that they will have defined behaviors.
This is kinda a gray area, but it's what it is.

Now for Rust, we shouldn't do what C code did previously that so atomics
have to be used in OnceLite, but when interacting with C, we can still
use the special rule of data races in kernel for reasoning, so the
"non-atomic operations" part in your argument shouldn't affect the
validity of OnceLite or SetOnce.

What I was missing, and I think you were pointing it correctly is that
SetOnce's internal logic doesn't handle a concurrent write to zero, even
if no "non-atomic operations" issue, this still breaks the
synchronization of SetOnce. It's like adding a invalidate() function for
SetOnce, that could invalidate the SetOnce at any time.

So yes, SetOnce may not be a good fit for OnceLite, but still OnceLite
should be in kernel::sync.

Hope I make it clear. Thanks!

Regards,
Boqun

> As I wrote before, in this particular case, I think that it would
> still work even if both atomic and non-atomic operations access the
> same variable though.
>
>
[..]