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
