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? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
