Re: [PATCH 5/6] rust: hrtimer: document deadlock when starting a timer in its handler

["Gary Guo" <gary@garyguo.net>]

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 <a.hindborg@kernel.org>
> ---
>  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`]