Re: [PATCH 2/2] drm/i915/pmu: Use a delayed wakeref put in get_rc6()

[sashiko-bot@kernel.org]

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 <umesh.nerlige.ramappa@intel.com>

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/20260910184253.1231313-4-umesh.nerlige.ramappa@intel.com?part=2