Re: [PATCH 5/6] rust: hrtimer: document deadlock when starting a timer in its handler
Andreas Hindborg <[email protected]>
| Newsgroups | org.kernel.vger.rust-for-linux,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
"Gary Guo" <[email protected]> writes: > 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". Right, I'll update the wording and comment. Best regards, Andreas Hindborg