Re: [PATCH v1 0/2] Add support for print exactly once

FUJITA Tomonori
2025-11-14T00:47:42Z

On Thu, 13 Nov 2025 12:06:17 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> On Thu, Nov 13, 2025 at 08:18:44PM +0900, FUJITA Tomonori wrote:
>> On Thu, 13 Nov 2025 10:07:36 +0000
>> Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> > On Wed, Nov 05, 2025 at 02:47:29PM +0900, FUJITA Tomonori wrote:
>> >> This adds the Rust equivalent of the kernel's DO_ONCE_LITE and
>> >> pr_*_once macros.
>> >>
>> >> A proposal for this feature was made in the past [1], but it didn't
>> >> reach consensus on the implementation and wasn't merged. After reading
>> >> the previous discussions, I implemented it using a different approach.
>> >>
>> >> In the previous proposal, a structure equivalent to std::sync::Once
>> >> was implemented to realize the DO_ONCE_LITE macro. The approach tried
>> >> to provide Once-like semantics by using two atomic values. As pointed
>> >> out in the previous review comments, I think this approach tries to
>> >> provide more functionality than needed, making it unnecessarily
>> >> complex. Also, because data structures in the .data..once section can
>> >> be cleared at any time (via debugfs clear_warn_once), an
>> >> implementation using two atomics wouldn't work correctly.
>> >>
>> >> Therefore, I decided to drop the idea of emulating Once and took a
>> >> minimal approach to implement DO_ONCE_LITE with only one atomic
>> >> variable. While it would be possible to implement the feature entirely
>> >> as a Rust macro, the functionality that can be implemented as regular
>> >> functions has been extracted and implemented as the OnceLite struct
>> >> for better code readability.
>> >>
>> >> Of course, unlike the previous proposal, this uses LKMM atomics.
>> >>
>> >> [1] https://lore.kernel.org/rust-for-linux/20241126-pr_once_macros-v4-0-410b8ca9643e@tuta.io/
>> >
>> > There has been a fair bit of discussion below. Here is my take on the
>> > way forward:
>> >
>> > 1. OnceLite should be it's own special type, and it should be in a
>> > printing-related module, not kernel::sync. The reason for this is
>> > that do_once_lite! is hooked up to a special section that allows you
>> > to reset the once status, and if someone used it for anything not
>> > related to printing, they would end up with being incorrectly reset
>> > when someone resets pr_warn_once calls.
>>
>> Do you mean that only the do_once_lite! macro, which places the data
>> in .data..once section, should live in a printing-related module? Or
>> should everything including OnceLite struct itself, also be moved
>> there?
>
> I think both should live in the same place, and not in kernel::sync.
> Whether you call the module once_lite or print is not a big deal to me.

Understood. In that case, it seems to me that either adding everything
to print.rs or creating a print/once_lite.rs would work well.

>> > 2. I would suggest just using a relaxed load followed by store instead
>> > of xchg. This is what the C-side does, and I think there is no strong
>> > reason to deviate. It allows for a single byte of data instead of i32.
>>
>> You meant best-effort try-once logic like C?
>>
>> pub fn call_once<F>(&self, f: F) -> bool
>> where
>> F: FnOnce(),
>> {
>> if self.0.load(Relaxed) == State::Incomplete {
>> self.0.store(State::Complete, Relaxed);
>> f();
>> return true;
>> }
>> false
>> }
>
> Yes that is what I meant.

Sounds good to me. As I wrote in another mail, I think that it's fine
to use the C-side logic here.

>> Using u8 as atomic type instead of i32 would require a fair amount of
>> work, since at the moment only i32 and i64 are supported as atomic
>> types, right?
>
> Supporting u8 atomics in general is tricky, but I think *specifically*
> load/store should not be a problem.

You meant using read_volatile/write_volatile? Since we only need
"Relaxed" order so something like the following?

#[repr(transparent)]
struct AtomicU8(UnsafeCell<u8>);

impl AtomicU8 {
#[inline(always)]
fn load(&self) -> u8 {
unsafe { core::ptr::read_volatile(self.0.get()) }
}

#[inline(always)]
fn store(&self, v: u8) {
unsafe { core::ptr::write_volatile(self.0.get(), v) }
}
}