On Tue Aug 25, 2026 at 1:16 PM BST, Andreas Hindborg wrote: > The state machine documentation states that for pointer types that > implement `Clone`, the `start` operation may be issued while the timer > is in the **running** state, and that it is then equivalent to the > `restart` operation. That only holds when the operation is issued from > outside the timer handler. > > The `start` operation returns a `HrTimerHandle`, and dropping the > handle cancels the timer with `hrtimer_cancel()`, which blocks until a > running handler has returned. When `start` is issued from within the > handler, the handle is also dropped within the handler, so the cancel > waits for the very handler that issues it, and the handler deadlocks.
That's not always true, you can start timer and store its handle elsewhere. I think the proper wording is that "cancelling a timer from within the timer handler will lead to deadlock". Best, Gary > > Note this in the state machine documentation. > > Signed-off-by: Andreas Hindborg <[email protected]> > --- > rust/kernel/time/hrtimer.rs | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs > index bdb6aaa22839..2a9abc9f5d8c 100644 > --- a/rust/kernel/time/hrtimer.rs > +++ b/rust/kernel/time/hrtimer.rs > @@ -78,6 +78,8 @@ > //! handler returns, and a restart requested by the return value of the > handler is discarded in > //! favor of the `restart` operation. > //! > +//! ⚠️ Issuing the `start` operation from within the timer handler will lead > to deadlock. > +//! > //! # Examples > //! > //! ## Using an intrusive timer living in a [`Box`]
