On Thu, Sep 10, 2026 at 06:54:18PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
to consider:
Pre-existing issues:
- [High] PMU callbacks acquire `spinlock_t` locks while the scheduler holds the
runqueue lock (`raw_spinlock_t`), violating lock nesting rules on PREEMPT_RT.
--
commit aeee9e0e0071ac1defceaf4b6ea0f13bad5f5898
Author: Umesh Nerlige Ramappa <[email protected]>
drm/i915/pmu: Use a delayed wakeref put in get_rc6()
This commit replaces intel_gt_pm_put_async() with intel_gt_pm_put_delay()
in get_rc6() to avoid waking a workqueue worker while the scheduler holds
the runqueue lock.
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c3bafda9c708..4598d9b5678a2 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -229,7 +229,12 @@ static u64 get_rc6(struct intel_gt *gt)
wakeref = intel_gt_pm_get_if_awake(gt);
if (wakeref) {
val = __get_rc6(gt);
- intel_gt_pm_put_async(gt, wakeref);
+ /*
+ * We are reached from the perf callbacks, which perf may invoke
+ * from the scheduler with the runqueue lock held. Defer the put
+ * on a timer so that it can never wake a task from here.
+ */
+ intel_gt_pm_put_delay(gt, wakeref, 1);
}
spin_lock_irqsave(&pmu->lock, flags);
[Severity: High]
This is a pre-existing issue, but does this still cause a lock nesting
violation on PREEMPT_RT?
Since get_rc6() is reached from PMU callbacks with the runqueue lock held
(which is a raw_spinlock_t), acquiring a spinlock_t here (pmu->lock) will
cause a scheduling while atomic panic on PREEMPT_RT kernels, because
spinlock_t becomes a sleepable rt_mutex.
Does __get_rc6() also trigger this panic? It looks like it acquires
uncore->lock via intel_rc6_residency_ns(), which is also a spinlock_t.
Similarly, guc_engine_busyness() appears to have the same underlying issue
with guc->timestamp.lock in the PMU callback path.
Are there plans to convert these locks to raw_spinlock_t or avoid acquiring
them entirely when called from perf scheduler contexts?
Valid issue. I will create a bug for this and track it as a separate
patch/series.
Umesh
--
Sashiko AI review ·
https://sashiko.dev/#/patchset/[email protected]?part=2
