Re: [PATCH 2/9] rust: hrtimer: add ArcHrTimerHandle::restart

"Mike Lothian" <[email protected]> writes:

> Restarting an already-started timer through the safe API means dropping
> its handle and calling `HrTimerPointer::start()` again. Dropping the
> handle cancels, and cancelling blocks until a running callback returns,
> so this is unavailable to any caller that cannot sleep -- a driver
> re-arming its timer from a callback invoked with interrupts disabled,
> say. Such drivers fall back to the unsafe `HasHrTimer::start()`
> on a raw pointer.
>
> Add `restart()` on the handle. It re-queues the timer in place without
> cancelling first. It is safe because the handle already owns the
> `Arc` that keeps the timer alive and still cancels it on drop, which
> is exactly what `HasHrTimer::start()` requires of its caller.

The intention is that handlers use the `forward` method on the context
object in combination with return value `HrTimerRestart::Restart` to re
arm the timer.

However, we found a data race in the face of concurrent `start`
operations, so we are solving that over at [1].


Best regards,
Andreas Hindborg


[1] https://lore.kernel.org/rust-for-linux/[email protected]/T/#t