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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Dropping `HrTimerHandle` from within its own timer callback deadlocks the CPU.
--

--- Patch [5]: [PATCH 5/6] rust: hrtimer: document deadlock when starting a timer in its handler ---
commit 728bf4e6c510d8fc30ab14edb4327239f3f07e2b
Author: Andreas Hindborg <[email protected]>

rust: hrtimer: document deadlock when starting a timer in its handler

This commit updates the hrtimer documentation to note that calling the
start operation from within the timer handler will lead to a deadlock.
This happens because the handle returned by start cancels the timer
when dropped, waiting for the current handler to finish.

> diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
> --- 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.

[Severity: High]
This is a pre-existing issue, but does relying on documentation here
leave safe Rust code vulnerable to triggering a kernel deadlock?

The handle types unconditionally invoke a synchronous cancel when dropped.
For example, looking at ArcHrTimerHandle:

rust/kernel/time/hrtimer/arc.rs:Drop for ArcHrTimerHandle {
    fn drop(&mut self) {
        self.cancel();
    }
}

This means if safe code invokes start() from within the timer callback
and allows the returned HrTimerHandle to drop, or replaces an existing
handle in a shared structure (implicitly dropping the old one), it will
block on hrtimer_cancel().

Since calling a synchronous cancel from the timer's own callback results
in a CPU deadlock, can safe Rust currently trigger a hard lockup just by
following standard drop patterns?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5