Received-SPF: pass (google.com: domain of linux-kernel+bounces-164582-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Andreas Hindborg <nmi@metaspace.dk>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Benno Lossin <benno.lossin@proton.me>,  Miguel Ojeda <ojeda@kernel.org>,
  Alex Gaynor <alex.gaynor@gmail.com>,  Wedson Almeida Filho
 <wedsonaf@gmail.com>,  Anna-Maria Behnsen <anna-maria@linutronix.de>,
  Frederic Weisbecker <frederic@kernel.org>,  Thomas Gleixner
 <tglx@linutronix.de>,  Andreas Hindborg <a.hindborg@samsung.com>,  Gary
 Guo <gary@garyguo.net>,  =?utf-8?Q?Bj=C3=B6rn?= Roy Baron
 <bjorn3_gh@protonmail.com>,
  Alice Ryhl <aliceryhl@google.com>,  rust-for-linux@vger.kernel.org,
  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: hrtimer: introduce hrtimer support
In-Reply-To: <ZjELgVzzX4oru0gi@Boquns-Mac-mini.home> (Boqun Feng's message of
	"Tue, 30 Apr 2024 08:17:21 -0700")
References: <20240425094634.262674-1-nmi@metaspace.dk>
	<a7a560c7-fb8c-4adf-9f46-2e272f24b335@proton.me>
	<87v844lbhm.fsf@metaspace.dk> <Zi_Zb1lBOBBUFJFV@boqun-archlinux>
	<87plu7jahd.fsf@metaspace.dk> <ZjELgVzzX4oru0gi@Boquns-Mac-mini.home>
User-Agent: mu4e 1.12.4; emacs 29.3
Date: Tue, 30 Apr 2024 20:22:25 +0200
Message-ID: <87h6fik8wu.fsf@metaspace.dk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Boqun Feng <boqun.feng@gmail.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.
>>=20
>> 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.
>>=20
>
> 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 =3D smp_load_acquire(&y);
> 					let r1 =3D 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 =3D=3D 1 && r1 =3D=
=3D 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` =F0=9F=91=8D

BR Andreas