On Tue, Sep 22, 2026 at 03:11:47PM -0700, Belgaumkar, Vinay wrote:
On 9/10/2026 11:42 AM, Umesh Nerlige Ramappa wrote:get_rc6() has the same runqueue lock deadlock as guc_engine_busyness(): it is reached from the PMU callbacks, which perf can invoke from the scheduler with the runqueue lock held, and intel_gt_pm_put_async() there can wake a workqueue worker via try_to_wake_up(). Use intel_gt_pm_put_delay() so the deferred put arms a timer instead. The remaining async puts in atomic contexts (hrtimer, tasklet, irq_work, G2H handlers) cannot run with the runqueue lock held and are left alone. Fixes: 07779a76ee1f ("drm/i915: Mark up the calling context for intel_wakeref_put()") Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Assisted-by: Claude:claude-opus-5 --- drivers/gpu/drm/i915/i915_pmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 1c3bafda9c70..4598d9b5678a 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 invokerephrase "We are reached"? There is another put_async in frequency_sample(). Do we need to update that as well?
engine/frequency_sample code is called from the hrtimer and there is no rq->lock held in this path, so this fix does not address any issues there. The specific issues reported was resulting in a deadlock because the rq->lock was held in the PMU call stack.
Thanks, Umesh
Thanks, Vinay.+ * 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);
