[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h6fik8wu.fsf@metaspace.dk>
Date: Tue, 30 Apr 2024 20:22:25 +0200
From: Andreas Hindborg <nmi@...aspace.dk>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho
<wedsonaf@...il.com>, Anna-Maria Behnsen <anna-maria@...utronix.de>,
Frederic Weisbecker <frederic@...nel.org>, Thomas Gleixner
<tglx@...utronix.de>, Andreas Hindborg <a.hindborg@...sung.com>, Gary
Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>,
Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: hrtimer: introduce hrtimer support
Boqun Feng <boqun.feng@...il.com> writes:
> On Tue, Apr 30, 2024 at 02:33:50PM +0200, Andreas Hindborg wrote:
> [...]
>> >
>> > Could you see if you can replace this with a `SpinLock<bool>` +
>> > `CondVar`? We shouldn't use Rust atomic in kernel now. I know it's
>> > unfortunate that LKMM atomics are still work in process, but in real
>> > world, you won't do busy waiting for a timer to fire, so a
>> > `CondVar::wait` is better for example purpose.
>>
>> Since this is only using the atomic from Rust code, it should be fine
>> right? There is no mixing of memory models on this memory location.
>>
>
> It's better compared to mixing accesses on a same location, but it's
> still not allowed (for now, at least) to avoid mixing memory models on
> ordering guarantees, for example:
>
> (assume all memory location is initialized as 0)
>
> CPU 0 CPU 1
> ----- -----
> x.store(1, RELAXED); // Rust native atomic
> smp_store_release(&y, 1); // LKMM atomic
> let r0 = smp_load_acquire(&y);
> let r1 = x.load(RELAXED);
>
> The smp_store_release() and smp_load_acquire() pairs per LKMM, and
> provide certain rel-acq ordering. But to make it (r0 == 1 && r1 == 0),
> C11 memory model needs to understand this sort of orderings, but
> currently there is no such thing as an "external ordering" to C11 memory
> model.
>
> I admit this is much of a theorical concern for code reasoning, in real
> world, it must "just work", but "if you want to have fun, start with
> one" ;-)
Alright, I will change it to a `CondVar` or a `SpinLock` 👍
BR Andreas
Powered by blists - more mailing lists