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 2/6] drm/i915/pmu: use the expiry injecting hrtimer callback
Date: Tue, 25 Aug 2026 12:29:42 +0000 [thread overview]
Message-ID: <20260825122943.69C531F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825-expires-v2-v1-2-90411c6217c7@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition in `i915_pmu_unregister()` allowing the timer to be rearmed after cancellation, leading to a use-after-free.
--
--- Patch [2]: [PATCH 2/6] drm/i915/pmu: use the expiry injecting hrtimer callback ---
commit 3544b866c523f970d22c7a2ae5ea50d0bc15978f
Author: Andreas Hindborg <a.hindborg@kernel.org>
drm/i915/pmu: use the expiry injecting hrtimer callback
The commit converts the i915 PMU sampling timer to use the expiry injecting
callback variant. This prevents a race condition between the timer callback
forwarding itself and concurrent timer restarts when the GT is unparked.
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 1c3bafda9c708..c18587e200c9f 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
[ ... ]
> @@ -1157,7 +1159,7 @@ void i915_pmu_register(struct drm_i915_private *i915)
> int ret = -ENOMEM;
>
> spin_lock_init(&pmu->lock);
> - hrtimer_setup(&pmu->timer, i915_sample, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + hrtimer_setup_ext(&pmu->timer, i915_sample, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
[Severity: High]
This is a pre-existing issue, but is there a race condition between the PMU
unregistration and GT unparking that can lead to a use-after-free?
Looking at i915_pmu_gt_unparked() in drivers/gpu/drm/i915/i915_pmu.c, it
performs a lockless check on pmu->registered before acquiring the lock:
drivers/gpu/drm/i915/i915_pmu.c:i915_pmu_gt_unparked() {
if (!pmu->registered)
return;
spin_lock_irq(&pmu->lock);
/*
* Re-enable sampling timer when GPU goes active.
*/
if (pmu->unparked == 0)
__i915_pmu_maybe_start_timer(pmu);
...
}
Concurrently, i915_pmu_unregister() sets pmu->registered to false and
cancels the timer:
drivers/gpu/drm/i915/i915_pmu.c:i915_pmu_unregister() {
...
/* Disconnect the PMU callbacks */
pmu->registered = false;
hrtimer_cancel(&pmu->timer);
...
}
If a user unparks the GT (e.g., by submitting a request) while the driver is
being removed, could i915_pmu_gt_unparked() read pmu->registered as true,
wait for the lock, and then rearm the timer after i915_pmu_unregister() has
already cancelled it?
When the drm_i915_private struct is later freed, would the rearmed timer
fire on freed memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260825-expires-v2-v1-0-90411c6217c7@kernel.org?part=2
next prev parent reply other threads:[~2026-08-25 12:29 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 [this message]
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
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=20260825122943.69C531F000E9@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.