From: sashiko-bot@kernel.org
To: "Andreas Hindborg" <a.hindborg@kernel.org>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
ojeda@kernel.org
Subject: Re: [PATCH 5/6] rust: hrtimer: document deadlock when starting a timer in its handler
Date: Tue, 25 Aug 2026 12:26:42 +0000 [thread overview]
Message-ID: <20260825122642.73CD21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825-expires-v2-v1-5-90411c6217c7@kernel.org>
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 <a.hindborg@kernel.org>
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/20260825-expires-v2-v1-0-90411c6217c7@kernel.org?part=5
next prev parent reply other threads:[~2026-08-25 12:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 12:16 [PATCH 0/6] hrtimer: add an expiry injecting callback variant Andreas Hindborg
2026-08-25 12:16 ` [PATCH 1/6] hrtimer: add " Andreas Hindborg
2026-09-29 20:56 ` Thomas Gleixner
2026-09-30 13:14 ` Gary Guo
2026-09-30 21:43 ` Thomas Gleixner
2026-09-30 23:29 ` Gary Guo
2026-10-01 13:45 ` Thomas Gleixner
2026-08-25 12:16 ` [PATCH 2/6] drm/i915/pmu: use the expiry injecting hrtimer callback Andreas Hindborg
2026-08-25 12:29 ` sashiko-bot
2026-08-25 12:16 ` [PATCH 3/6] rust: hrtimer: use the expiry injecting callback variant Andreas Hindborg
2026-08-25 12:33 ` sashiko-bot
2026-08-25 12:16 ` [PATCH 4/6] rust: hrtimer: restrict expires() to exclusive access Andreas Hindborg
2026-08-25 12:25 ` sashiko-bot
2026-08-25 12:16 ` [PATCH 5/6] rust: hrtimer: document deadlock when starting a timer in its handler Andreas Hindborg
2026-08-25 12:26 ` sashiko-bot [this message]
2026-08-25 13:31 ` Gary Guo
2026-08-26 9:31 ` Andreas Hindborg
2026-08-25 12:16 ` [PATCH 6/6] rust: hrtimer: Make HrTimer repr(transparent) Andreas Hindborg
2026-08-25 12:30 ` sashiko-bot
2026-08-25 13:33 ` Gary Guo
2026-08-26 9:30 ` Andreas Hindborg
2026-08-26 22:23 ` ✓ i915.CI.BAT: success for hrtimer: add an expiry injecting callback variant Patchwork
2026-08-27 6:28 ` ✗ i915.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260825122642.73CD21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.