All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH] drm/xe: Fix lockdep warning in xe_force_wake calls
Date: Fri, 17 Nov 2023 14:18:01 +0530	[thread overview]
Message-ID: <37cb2bd7-dfbb-c96d-c5d7-8a318a20dd70@linux.intel.com> (raw)
In-Reply-To: <ZU4tWZXqWSlIG7GZ@DUT025-TGLU.fm.intel.com>


On 10/11/23 18:47, Matthew Brost wrote:
> On Fri, Nov 10, 2023 at 11:59:07AM +0530, Aravind Iddamsetty wrote:
>> Use spin_lock_irqsave, spin_unlock_irqrestore
>>
>> Fix for below:
>> [13994.811263] ========================================================
>> [13994.811295] WARNING: possible irq lock inversion dependency detected
>> [13994.811326] 6.6.0-rc3-xe #2 Tainted: G     U
>> [13994.811358] --------------------------------------------------------
>> [13994.811388] swapper/0/0 just changed the state of lock:
>> [13994.811416] ffff895c7e044db8 (&cpuctx_lock){-...}-{2:2}, at:
>> __perf_event_read+0xb7/0x3a0
>> [13994.811494] but this lock took another, HARDIRQ-unsafe lock in the
>> past:
>> [13994.811528]  (&fw->lock){+.+.}-{2:2}
>> [13994.811544]
>>
>>                and interrupts could create inverse lock ordering between
>> them.
>>
>> [13994.811606]
>>                other info that might help us debug this:
>> [13994.811636]  Possible interrupt unsafe locking scenario:
>>
>> [13994.811667]        CPU0                    CPU1
>> [13994.811691]        ----                    ----
>> [13994.811715]   lock(&fw->lock);
>> [13994.811744]                                local_irq_disable();
>> [13994.811773]                                lock(&cpuctx_lock);
>> [13994.811810]                                lock(&fw->lock);
>> [13994.811846]   <Interrupt>
>> [13994.811865]     lock(&cpuctx_lock);
>> [13994.811895]
>>                 *** DEADLOCK ***
>>
Hi Matt,

Firstly thanks for your comment and sorry for the late response was OOO on sick the entire week.

> I don't personally like this. Where in an irq context do we grab this
> lock? FW probably shouldn't ever be grabbed from an irq context. I see
> this was changed from a mutex to spin lock in which is pretty suspect
> IMO.
with the PMU interface "drm/xe/pmu: Enable PMU interface" we are exposing engine busyness
counters and the registers fall under GT domain and needed forcewake as PMU is atomic context
so had to change the forcewake to use spinlock. But other than this i do not think forcewake
is being called from any irq context, AFAIU lockdep is predicting a scenario and hence the
warning. which subsided by use of spin_lock_irqsave.


>
> 'drm/xe: Use spinlock in forcewake instead of mutex'  
>
> If this really needs to be a spin lock I'd rather have versions of
> xe_force_wake_get/put that called from non-atomic contexts (e.g. use
> spin_lock_irq) and atomic contexts (e.g. use spin_lock) rather than
> using spin_lock_irqsave.

I somehow doubt if lockdep be able to recognize such a use and not warn again.

Thanks,
Aravind.
>
> Matt
>
>> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
>> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>
>> ---
>>  drivers/gpu/drm/xe/xe_force_wake.c | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_force_wake.c b/drivers/gpu/drm/xe/xe_force_wake.c
>> index 32d6c4dd2807..9bbe8a5040da 100644
>> --- a/drivers/gpu/drm/xe/xe_force_wake.c
>> +++ b/drivers/gpu/drm/xe/xe_force_wake.c
>> @@ -145,9 +145,10 @@ int xe_force_wake_get(struct xe_force_wake *fw,
>>  	struct xe_gt *gt = fw_to_gt(fw);
>>  	struct xe_force_wake_domain *domain;
>>  	enum xe_force_wake_domains tmp, woken = 0;
>> +	unsigned long flags;
>>  	int ret, ret2 = 0;
>>  
>> -	spin_lock(&fw->lock);
>> +	spin_lock_irqsave(&fw->lock, flags);
>>  	for_each_fw_domain_masked(domain, domains, fw, tmp) {
>>  		if (!domain->ref++) {
>>  			woken |= BIT(domain->id);
>> @@ -162,7 +163,7 @@ int xe_force_wake_get(struct xe_force_wake *fw,
>>  				   domain->id, ret);
>>  	}
>>  	fw->awake_domains |= woken;
>> -	spin_unlock(&fw->lock);
>> +	spin_unlock_irqrestore(&fw->lock, flags);
>>  
>>  	return ret2;
>>  }
>> @@ -174,9 +175,10 @@ int xe_force_wake_put(struct xe_force_wake *fw,
>>  	struct xe_gt *gt = fw_to_gt(fw);
>>  	struct xe_force_wake_domain *domain;
>>  	enum xe_force_wake_domains tmp, sleep = 0;
>> +	unsigned long flags;
>>  	int ret, ret2 = 0;
>>  
>> -	spin_lock(&fw->lock);
>> +	spin_lock_irqsave(&fw->lock, flags);
>>  	for_each_fw_domain_masked(domain, domains, fw, tmp) {
>>  		if (!--domain->ref) {
>>  			sleep |= BIT(domain->id);
>> @@ -191,7 +193,7 @@ int xe_force_wake_put(struct xe_force_wake *fw,
>>  				   domain->id, ret);
>>  	}
>>  	fw->awake_domains &= ~sleep;
>> -	spin_unlock(&fw->lock);
>> +	spin_unlock_irqrestore(&fw->lock, flags);
>>  
>>  	return ret2;
>>  }
>> -- 
>> 2.25.1
>>

  reply	other threads:[~2023-11-17  8:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-10  6:29 [Intel-xe] [PATCH] drm/xe: Fix lockdep warning in xe_force_wake calls Aravind Iddamsetty
2023-11-10  6:40 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-11-10  6:41 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-11-10  6:42 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-11-10  6:49 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-10  6:49 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-11-10  6:51 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-11-10 13:17 ` [Intel-xe] [PATCH] " Matthew Brost
2023-11-17  8:48   ` Aravind Iddamsetty [this message]
2023-11-20 12:32     ` Matthew Brost
  -- strict thread matches above, loose matches on Subject: below --
2023-11-24  6:44 Aravind Iddamsetty
2023-11-24  7:19 ` Ville Syrjälä
2023-11-24  8:31   ` Aravind Iddamsetty
2023-11-24  8:37     ` Ville Syrjälä
2023-11-28  8:30       ` Aravind Iddamsetty
2023-12-01  3:37         ` Aravind Iddamsetty
2023-12-06  9:53 Aravind Iddamsetty
2023-12-08  5:17 ` Rodrigo Vivi
2023-12-08  5:49   ` Aravind Iddamsetty

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=37cb2bd7-dfbb-c96d-c5d7-8a318a20dd70@linux.intel.com \
    --to=aravind.iddamsetty@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    /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.