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

FUJITA Tomonori
2025-11-11T01:28:52Z

On Mon, 10 Nov 2025 13:16:44 +0100
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> Boqun Feng <boqun.feng@gmail.com> writes:
>
>> On Thu, Nov 06, 2025 at 08:12:31AM +0900, FUJITA Tomonori wrote:
>>> On Wed, 05 Nov 2025 21:59:06 +0100
>>> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>>
>>> > "FUJITA Tomonori" <fujita.tomonori@gmail.com> writes:
>>> >
>>> >> 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.
>>> >
>>> > Please consider if it makes sense to base this on `SetOnce`. It is in
>>> > linux-next now, but was on list here [1].
>>>
>>> Data placed in the .data..once section can be zero-cleared when a user
>>> writes to debugfs clear_warn_once. In that case, would such data still
>>> be considered a valid SetOnce value?
>>>
>>
>> It's still a valid value I believe. In term of data races, Rust and C
>> have no difference, so if writing to debugfs could cause issues in Rust,
>> it would cause issues in C as well.
>
> @Tomo you are right, `SetOnce` would not work with someone (debugfs)
> asynchronously modifying the state atomic variable. It requires
> exclusive access while writing the contained value.

Yeah, I believe that SetOnce assumes that both init and value fields
are modified only through its methods, and it's not intended to handle
external modifications such those done with memset.

For this use-case, SetOnce would still work even if used that way,
though it's not the intended or recommended usage, I think.