Received-SPF: pass (google.com: domain of linux-kernel+bounces-165192-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Andreas Hindborg <nmi@metaspace.dk>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: 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>,
  Andreas Hindborg <a.hindborg@samsung.com>,  Boqun Feng
 <boqun.feng@gmail.com>,  Gary Guo <gary@garyguo.net>,  =?utf-8?Q?Bj=C3=B6?=
 =?utf-8?Q?rn?= Roy Baron
 <bjorn3_gh@protonmail.com>,  Benno Lossin <benno.lossin@proton.me>,  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: <87ikzysd36.ffs@tglx> (Thomas Gleixner's message of "Wed, 01 May
	2024 00:25:01 +0200")
References: <20240425094634.262674-1-nmi@metaspace.dk> <87r0emss0j.ffs@tglx>
	<87le4uk936.fsf@metaspace.dk> <87ikzysd36.ffs@tglx>
User-Agent: mu4e 1.12.4; emacs 29.3
Date: Wed, 01 May 2024 13:37:00 +0200
Message-ID: <87cyq5kbkz.fsf@metaspace.dk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thomas Gleixner <tglx@linutronix.de> writes:

> Andreas!
>
> On Tue, Apr 30 2024 at 20:18, Andreas Hindborg wrote:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>>> On Thu, Apr 25 2024 at 11:46, Andreas Hindborg wrote:
>>>> +// SAFETY: A `Timer` can be moved to other threads and used from ther=
e.
>>>> +unsafe impl<T> Send for Timer<T> {}
>>>> +
>>>> +// SAFETY: Timer operations are locked on C side, so it is safe to op=
erate on a
>>>> +// timer from multiple threads
>>>
>>> Kinda. Using an hrtimer from different threads needs some thought in the
>>> implementation as obviously ordering matters:
>>>
>>>      T1                              T2
>>>      hrtimer_start()                 hrtimer_cancel()
>>>
>>> So depending on whether T1 gets the internal lock first or T2 the
>>> outcome is different. If T1 gets it first the timer is canceled by
>>> T2. If T2 gets it first the timer ends up armed.
>>
>> That is all fine. What is meant here is that we will not get UB in the
>> `hrtimer` subsystem when racing these operations. As far as I can tell
>> from the C source, the operations are atomic, even though their
>> interleaving will not be deterministic.
>
> That's correct. All operations happen with the associated base lock held.
>
>>>> +unsafe impl<T> Sync for Timer<T> {}
>>>> +
>>>> +impl<T: TimerCallback> Timer<T> {
>>>> +    /// Return an initializer for a new timer instance.
>>>> +    pub fn new() -> impl PinInit<Self> {
>>>> +        crate::pin_init!( Self {
>>>> +            timer <- Opaque::ffi_init(move |place: *mut bindings::hrt=
imer| {
>>>> +                // SAFETY: By design of `pin_init!`, `place` is a poi=
nter live
>>>> +                // allocation. hrtimer_init will initialize `place` a=
nd does not
>>>> +                // require `place` to be initialized prior to the cal=
l.
>>>> +                unsafe {
>>>> +                    bindings::hrtimer_init(
>>>> +                        place,
>>>> +                        bindings::CLOCK_MONOTONIC as i32,
>>>> +                        bindings::hrtimer_mode_HRTIMER_MODE_REL,
>>>
>>> This is odd. The initializer really should take a clock ID and a mode
>>> argument. Otherwise you end up implementing a gazillion of different
>>> timers.
>>
>> I implemented the minimum set of features to satisfy the requirements
>> for the Rust null block driver. It is my understanding that most
>> maintainers of existing infrastructure prefers to have a user for the
>> implemented features, before wanting to merge them.
>>
>> I can try to extend the abstractions to cover a more complete `hrtimer`
>> API. Or we can work on this subset and try to get that ready to merge,
>> and then expand scope later.
>
> Wouldn't expanding scope later require to change already existing call si=
tes?

Yes, potentially. But I hear that Coccinelle is gaining Rust support =F0=9F=
=91=8D

>
>>>> +                    );
>>>> +                }
>>>> +
>>>> +                // SAFETY: `place` is pointing to a live allocation, =
so the deref
>>>> +                // is safe. The `function` field might not be initial=
ized, but
>>>> +                // `addr_of_mut` does not create a reference to the f=
ield.
>>>> +                let function: *mut Option<_> =3D unsafe { core::ptr::=
addr_of_mut!((*place).function) };
>>>> +
>>>> +                // SAFETY: `function` points to a valid allocation.
>>>> +                unsafe { core::ptr::write(function, Some(T::Receiver:=
:run)) };
>>>
>>> We probably should introduce hrtimer_setup(timer, clockid, mode, functi=
on)
>>> to avoid this construct. That would allow to cleanup existing C code to=
o.
>>
>> Do you want me to cook up a C patch for that, or would you prefer to do
>> that yourself?
>
> Please create that patch yourself and convert at least one C location to
> this new interface in a separate patch. THe remaining C cleanup can go
> from there and mostly be scripted with coccinelle.

Ok.

>
>>>> +/// [`Box<T>`]: Box
>>>> +/// [`Arc<T>`]: Arc
>>>> +/// [`ARef<T>`]: crate::types::ARef
>>>> +pub trait RawTimer: Sync {
>>>> +    /// Schedule the timer after `expires` time units
>>>> +    fn schedule(self, expires: u64);
>>>
>>> Don't we have some time related rust types in the kernel by now?
>>
>> There are patches on the list, but I think they are not applied to any
>> tree yet? I did not want to depend on those patches before they are
>> staged somewhere. Would you prefer this patch on top of the Rust `ktime`
>> patches?
>
> The initial set is queued in
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>
> for 6.10. Boqun has some updates on top IIRC. Your stuff should go
> through that branch too.

Ok.

>
>>>> +        // SAFETY: This `Arc` comes from a call to `Arc::into_raw()`
>>>> +        let receiver =3D unsafe { Arc::from_raw(data_ptr) };
>>>> +
>>>> +        T::run(receiver);
>>>> +
>>>> +        bindings::hrtimer_restart_HRTIMER_NORESTART
>>>
>>> One of the common use cases of hrtimers is to create periodic schedules
>>> where the timer callback advances the expiry value and returns
>>> HRTIMER_RESTART. It might be not required for your initial use case at
>>> hand, but you'll need that in the long run IMO.
>>
>> If you are OK with taking that feature without a user, I will gladly add
>> it.
>
> I'm fine with taking a more complete API which does not require to
> change usage sites later on.

I will expand the API and send an updated patch when that is done =F0=9F=91=
=8D

BR Andreas