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

From
Andreas Hindborg <a.hindborg@kernel.org>
Date
2026-08-26 09:31:33
Also in
dri-devel, intel-gfx, lkml
Reply to
Gary Guo, 2026-08-25
"Gary Guo" [off-list ref] writes:
On Tue Aug 25, 2026 at 1:16 PM BST, Andreas Hindborg wrote:
quoted
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".
Right, I'll update the wording and comment.


Best regards,
Andreas Hindborg

Thread (16 messages) 16 messages, 3 authors, last reply 2026-10-01
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help