mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
@ 2025-11-04  9:53 Pierre-Eric Pelloux-Prayer
  2025-11-04 12:43 ` Philipp Stanner
  2025-11-05 11:32 ` Philipp Stanner
  0 siblings, 2 replies; 6+ messages in thread
From: Pierre-Eric Pelloux-Prayer @ 2025-11-04  9:53 UTC (permalink / raw)
  To: Matthew Brost, Danilo Krummrich, Philipp Stanner,
	Christian König, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
	Luben Tuikov
  Cc: Pierre-Eric Pelloux-Prayer, Mikhail Gavrilov,
	Christian König, dri-devel, linux-kernel, linux-media,
	linaro-mm-sig

The Mesa issue referenced below pointed out a possible deadlock:

[ 1231.611031]  Possible interrupt unsafe locking scenario:

[ 1231.611033]        CPU0                    CPU1
[ 1231.611034]        ----                    ----
[ 1231.611035]   lock(&xa->xa_lock#17);
[ 1231.611038]                                local_irq_disable();
[ 1231.611039]                                lock(&fence->lock);
[ 1231.611041]                                lock(&xa->xa_lock#17);
[ 1231.611044]   <Interrupt>
[ 1231.611045]     lock(&fence->lock);
[ 1231.611047]
                *** DEADLOCK ***

In this example, CPU0 would be any function accessing job->dependencies
through the xa_* functions that doesn't disable interrupts (eg:
drm_sched_job_add_dependency, drm_sched_entity_kill_jobs_cb).

CPU1 is executing drm_sched_entity_kill_jobs_cb as a fence signalling
callback so in an interrupt context. It will deadlock when trying to
grab the xa_lock which is already held by CPU0.

Replacing all xa_* usage by their xa_*_irq counterparts would fix
this issue, but Christian pointed out another issue: dma_fence_signal
takes fence.lock and so does dma_fence_add_callback.

  dma_fence_signal() // locks f1.lock
  -> drm_sched_entity_kill_jobs_cb()
  -> foreach dependencies
     -> dma_fence_add_callback() // locks f2.lock

This will deadlock if f1 and f2 share the same spinlock.

To fix both issues, the code iterating on dependencies and re-arming them
is moved out to drm_sched_entity_kill_jobs_work.

v2: reworded commit message (Philipp)
v3: added Fixes tag (Philipp)

Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
---
 drivers/gpu/drm/scheduler/sched_entity.c | 34 +++++++++++++-----------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
index c8e949f4a568..fe174a4857be 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -173,26 +173,15 @@ int drm_sched_entity_error(struct drm_sched_entity *entity)
 }
 EXPORT_SYMBOL(drm_sched_entity_error);
 
+static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
+					  struct dma_fence_cb *cb);
+
 static void drm_sched_entity_kill_jobs_work(struct work_struct *wrk)
 {
 	struct drm_sched_job *job = container_of(wrk, typeof(*job), work);
-
-	drm_sched_fence_scheduled(job->s_fence, NULL);
-	drm_sched_fence_finished(job->s_fence, -ESRCH);
-	WARN_ON(job->s_fence->parent);
-	job->sched->ops->free_job(job);
-}
-
-/* Signal the scheduler finished fence when the entity in question is killed. */
-static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
-					  struct dma_fence_cb *cb)
-{
-	struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-						 finish_cb);
+	struct dma_fence *f;
 	unsigned long index;
 
-	dma_fence_put(f);
-
 	/* Wait for all dependencies to avoid data corruptions */
 	xa_for_each(&job->dependencies, index, f) {
 		struct drm_sched_fence *s_fence = to_drm_sched_fence(f);
@@ -220,6 +209,21 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
 		dma_fence_put(f);
 	}
 
+	drm_sched_fence_scheduled(job->s_fence, NULL);
+	drm_sched_fence_finished(job->s_fence, -ESRCH);
+	WARN_ON(job->s_fence->parent);
+	job->sched->ops->free_job(job);
+}
+
+/* Signal the scheduler finished fence when the entity in question is killed. */
+static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
+					  struct dma_fence_cb *cb)
+{
+	struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
+						 finish_cb);
+
+	dma_fence_put(f);
+
 	INIT_WORK(&job->work, drm_sched_entity_kill_jobs_work);
 	schedule_work(&job->work);
 }
-- 
2.43.0


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  2025-11-04  9:53 [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb Pierre-Eric Pelloux-Prayer
@ 2025-11-04 12:43 ` Philipp Stanner
  2025-11-04 15:24   ` Pierre-Eric Pelloux-Prayer
  2025-11-05 11:32 ` Philipp Stanner
  1 sibling, 1 reply; 6+ messages in thread
From: Philipp Stanner @ 2025-11-04 12:43 UTC (permalink / raw)
  To: Pierre-Eric Pelloux-Prayer, Matthew Brost, Danilo Krummrich,
	Philipp Stanner, Christian König, Maarten Lankhorst,
	Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
	Sumit Semwal, Luben Tuikov
  Cc: Mikhail Gavrilov, Christian König, dri-devel, linux-kernel,
	linux-media, linaro-mm-sig

On Tue, 2025-11-04 at 10:53 +0100, Pierre-Eric Pelloux-Prayer wrote:
> The Mesa issue referenced below pointed out a possible deadlock:
> 
> [ 1231.611031]  Possible interrupt unsafe locking scenario:
> 
> [ 1231.611033]        CPU0                    CPU1
> [ 1231.611034]        ----                    ----
> [ 1231.611035]   lock(&xa->xa_lock#17);
> [ 1231.611038]                                local_irq_disable();
> [ 1231.611039]                                lock(&fence->lock);
> [ 1231.611041]                                lock(&xa->xa_lock#17);
> [ 1231.611044]   <Interrupt>
> [ 1231.611045]     lock(&fence->lock);
> [ 1231.611047]
>                 *** DEADLOCK ***
> 
> In this example, CPU0 would be any function accessing job->dependencies
> through the xa_* functions that doesn't disable interrupts (eg:
> drm_sched_job_add_dependency, drm_sched_entity_kill_jobs_cb).
> 
> CPU1 is executing drm_sched_entity_kill_jobs_cb as a fence signalling
> callback so in an interrupt context. It will deadlock when trying to
> grab the xa_lock which is already held by CPU0.
> 
> Replacing all xa_* usage by their xa_*_irq counterparts would fix
> this issue, but Christian pointed out another issue: dma_fence_signal
> takes fence.lock and so does dma_fence_add_callback.
> 
>   dma_fence_signal() // locks f1.lock
>   -> drm_sched_entity_kill_jobs_cb()
>   -> foreach dependencies
>      -> dma_fence_add_callback() // locks f2.lock
> 
> This will deadlock if f1 and f2 share the same spinlock.
> 
> To fix both issues, the code iterating on dependencies and re-arming them
> is moved out to drm_sched_entity_kill_jobs_work.
> 
> v2: reworded commit message (Philipp)
> v3: added Fixes tag (Philipp)

Thx for the update.
In the future please put the changelog below between a pair of '---'

---
v2: …
v3: …
---

Some things I have unfortunately overlooked below.

> 
> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")

We should +Cc stable. It's a deadlock after all.

> Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 34 +++++++++++++-----------
>  1 file changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> index c8e949f4a568..fe174a4857be 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -173,26 +173,15 @@ int drm_sched_entity_error(struct drm_sched_entity *entity)
>  }
>  EXPORT_SYMBOL(drm_sched_entity_error);
>  
> +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
> +					  struct dma_fence_cb *cb);

It's far better to move the function up instead. Can you do that?

> +
> 

[…]

> +/* Signal the scheduler finished fence when the entity in question is killed. */
> +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
> +					  struct dma_fence_cb *cb)
> +{
> +	struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
> +						 finish_cb);
> +
> +	dma_fence_put(f);

It would be great if we knew what fence is being dropped here and why.
I know you're just moving the pre-existing code, but if you should
know, informing about that via comment would be great.

Optional.


Rest of the code looks good. No further objections.


P.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  2025-11-04 12:43 ` Philipp Stanner
@ 2025-11-04 15:24   ` Pierre-Eric Pelloux-Prayer
  2025-11-04 15:30     ` Philipp Stanner
  0 siblings, 1 reply; 6+ messages in thread
From: Pierre-Eric Pelloux-Prayer @ 2025-11-04 15:24 UTC (permalink / raw)
  To: phasta, Pierre-Eric Pelloux-Prayer, Matthew Brost,
	Danilo Krummrich, Christian König, Maarten Lankhorst,
	Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
	Sumit Semwal, Luben Tuikov
  Cc: Mikhail Gavrilov, Christian König, dri-devel, linux-kernel,
	linux-media, linaro-mm-sig



Le 04/11/2025 à 13:43, Philipp Stanner a écrit :
> On Tue, 2025-11-04 at 10:53 +0100, Pierre-Eric Pelloux-Prayer wrote:
>> The Mesa issue referenced below pointed out a possible deadlock:
>>
>> [ 1231.611031]  Possible interrupt unsafe locking scenario:
>>
>> [ 1231.611033]        CPU0                    CPU1
>> [ 1231.611034]        ----                    ----
>> [ 1231.611035]   lock(&xa->xa_lock#17);
>> [ 1231.611038]                                local_irq_disable();
>> [ 1231.611039]                                lock(&fence->lock);
>> [ 1231.611041]                                lock(&xa->xa_lock#17);
>> [ 1231.611044]   <Interrupt>
>> [ 1231.611045]     lock(&fence->lock);
>> [ 1231.611047]
>>                  *** DEADLOCK ***
>>
>> In this example, CPU0 would be any function accessing job->dependencies
>> through the xa_* functions that doesn't disable interrupts (eg:
>> drm_sched_job_add_dependency, drm_sched_entity_kill_jobs_cb).
>>
>> CPU1 is executing drm_sched_entity_kill_jobs_cb as a fence signalling
>> callback so in an interrupt context. It will deadlock when trying to
>> grab the xa_lock which is already held by CPU0.
>>
>> Replacing all xa_* usage by their xa_*_irq counterparts would fix
>> this issue, but Christian pointed out another issue: dma_fence_signal
>> takes fence.lock and so does dma_fence_add_callback.
>>
>>    dma_fence_signal() // locks f1.lock
>>    -> drm_sched_entity_kill_jobs_cb()
>>    -> foreach dependencies
>>       -> dma_fence_add_callback() // locks f2.lock
>>
>> This will deadlock if f1 and f2 share the same spinlock.
>>
>> To fix both issues, the code iterating on dependencies and re-arming them
>> is moved out to drm_sched_entity_kill_jobs_work.
>>
>> v2: reworded commit message (Philipp)
>> v3: added Fixes tag (Philipp)
> 
> Thx for the update.
> In the future please put the changelog below between a pair of '---'
> 
> ---
> v2: …
> v3: …
> ---

OK.

> 
> Some things I have unfortunately overlooked below.
> 
>>
>> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> 
> We should +Cc stable. It's a deadlock after all.

OK.

> 
>> Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
>> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
>> Suggested-by: Christian König <christian.koenig@amd.com>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>> ---
>>   drivers/gpu/drm/scheduler/sched_entity.c | 34 +++++++++++++-----------
>>   1 file changed, 19 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
>> index c8e949f4a568..fe174a4857be 100644
>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>> @@ -173,26 +173,15 @@ int drm_sched_entity_error(struct drm_sched_entity *entity)
>>   }
>>   EXPORT_SYMBOL(drm_sched_entity_error);
>>   
>> +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
>> +					  struct dma_fence_cb *cb);
> 
> It's far better to move the function up instead. Can you do that?

Since drm_sched_entity_kill_jobs_cb uses drm_sched_entity_kill_jobs and vice 
versa, I'll have to forward declare one of the 2 functions anyway.


> 
>> +
>>
> 
> […]
> 
>> +/* Signal the scheduler finished fence when the entity in question is killed. */
>> +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
>> +					  struct dma_fence_cb *cb)
>> +{
>> +	struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
>> +						 finish_cb);
>> +
>> +	dma_fence_put(f);
> 
> It would be great if we knew what fence is being dropped here and why.
> I know you're just moving the pre-existing code, but if you should
> know, informing about that via comment would be great.
> 

As discussed offline, "f" is simply the fence being signaled, I'm not sure it 
warrants a comment.

Regards,
Pierre-Eric

> Optional.
> 
> 
> Rest of the code looks good. No further objections.
> 
> 
> P.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  2025-11-04 15:24   ` Pierre-Eric Pelloux-Prayer
@ 2025-11-04 15:30     ` Philipp Stanner
  2025-11-04 15:34       ` Pierre-Eric Pelloux-Prayer
  0 siblings, 1 reply; 6+ messages in thread
From: Philipp Stanner @ 2025-11-04 15:30 UTC (permalink / raw)
  To: Pierre-Eric Pelloux-Prayer, phasta, Pierre-Eric Pelloux-Prayer,
	Matthew Brost, Danilo Krummrich, Christian König,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Simona Vetter, Sumit Semwal, Luben Tuikov
  Cc: Mikhail Gavrilov, Christian König, dri-devel, linux-kernel,
	linux-media, linaro-mm-sig

On Tue, 2025-11-04 at 16:24 +0100, Pierre-Eric Pelloux-Prayer wrote:
> 
> 
> Le 04/11/2025 à 13:43, Philipp Stanner a écrit :
> 
> > 
> > Some things I have unfortunately overlooked below.
> > 
> > > 
> > > Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> > 
> > We should +Cc stable. It's a deadlock after all.
> 
> OK.
> 
> > 
> > > Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
> > > Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> > > Suggested-by: Christian König <christian.koenig@amd.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
> > > ---
> > >   drivers/gpu/drm/scheduler/sched_entity.c | 34 +++++++++++++-----------
> > >   1 file changed, 19 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> > > index c8e949f4a568..fe174a4857be 100644
> > > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > > @@ -173,26 +173,15 @@ int drm_sched_entity_error(struct drm_sched_entity *entity)
> > >   }
> > >   EXPORT_SYMBOL(drm_sched_entity_error);
> > >   
> > > +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
> > > +					  struct dma_fence_cb *cb);
> > 
> > It's far better to move the function up instead. Can you do that?
> 
> Since drm_sched_entity_kill_jobs_cb uses drm_sched_entity_kill_jobs and vice 
> versa, I'll have to forward declare one of the 2 functions anyway.

Ah, right.
OK then.

I can push this and +Cc stable in the commit message if you want.


P.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  2025-11-04 15:30     ` Philipp Stanner
@ 2025-11-04 15:34       ` Pierre-Eric Pelloux-Prayer
  0 siblings, 0 replies; 6+ messages in thread
From: Pierre-Eric Pelloux-Prayer @ 2025-11-04 15:34 UTC (permalink / raw)
  To: phasta, Pierre-Eric Pelloux-Prayer, Matthew Brost,
	Danilo Krummrich, Christian König, Maarten Lankhorst,
	Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
	Sumit Semwal
  Cc: Mikhail Gavrilov, Christian König, dri-devel, linux-kernel,
	linux-media



Le 04/11/2025 à 16:30, Philipp Stanner a écrit :
> On Tue, 2025-11-04 at 16:24 +0100, Pierre-Eric Pelloux-Prayer wrote:
>>
>>
>> Le 04/11/2025 à 13:43, Philipp Stanner a écrit :
>>
>>>
>>> Some things I have unfortunately overlooked below.
>>>
>>>>
>>>> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
>>>
>>> We should +Cc stable. It's a deadlock after all.
>>
>> OK.
>>
>>>
>>>> Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
>>>> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
>>>> Suggested-by: Christian König <christian.koenig@amd.com>
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>>>> ---
>>>>    drivers/gpu/drm/scheduler/sched_entity.c | 34 +++++++++++++-----------
>>>>    1 file changed, 19 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
>>>> index c8e949f4a568..fe174a4857be 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>>>> @@ -173,26 +173,15 @@ int drm_sched_entity_error(struct drm_sched_entity *entity)
>>>>    }
>>>>    EXPORT_SYMBOL(drm_sched_entity_error);
>>>>    
>>>> +static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
>>>> +					  struct dma_fence_cb *cb);
>>>
>>> It's far better to move the function up instead. Can you do that?
>>
>> Since drm_sched_entity_kill_jobs_cb uses drm_sched_entity_kill_jobs and vice
>> versa, I'll have to forward declare one of the 2 functions anyway.
> 
> Ah, right.
> OK then.
> 
> I can push this and +Cc stable in the commit message if you want.
> 

Would be great, thanks!

Pierre-Eric


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  2025-11-04  9:53 [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb Pierre-Eric Pelloux-Prayer
  2025-11-04 12:43 ` Philipp Stanner
@ 2025-11-05 11:32 ` Philipp Stanner
  1 sibling, 0 replies; 6+ messages in thread
From: Philipp Stanner @ 2025-11-05 11:32 UTC (permalink / raw)
  To: Pierre-Eric Pelloux-Prayer, Matthew Brost, Danilo Krummrich,
	Philipp Stanner, Christian König, Maarten Lankhorst,
	Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
	Sumit Semwal, Luben Tuikov
  Cc: Mikhail Gavrilov, Christian König, dri-devel, linux-kernel,
	linux-media, linaro-mm-sig

On Tue, 2025-11-04 at 10:53 +0100, Pierre-Eric Pelloux-Prayer wrote:
> The Mesa issue referenced below pointed out a possible deadlock:
> 
> [ 1231.611031]  Possible interrupt unsafe locking scenario:
> 
> [ 1231.611033]        CPU0                    CPU1
> [ 1231.611034]        ----                    ----
> [ 1231.611035]   lock(&xa->xa_lock#17);
> [ 1231.611038]                                local_irq_disable();
> [ 1231.611039]                                lock(&fence->lock);
> [ 1231.611041]                                lock(&xa->xa_lock#17);
> [ 1231.611044]   <Interrupt>
> [ 1231.611045]     lock(&fence->lock);
> [ 1231.611047]
>                 *** DEADLOCK ***
> 
> In this example, CPU0 would be any function accessing job->dependencies
> through the xa_* functions that doesn't disable interrupts (eg:
> drm_sched_job_add_dependency, drm_sched_entity_kill_jobs_cb).
> 
> CPU1 is executing drm_sched_entity_kill_jobs_cb as a fence signalling
> callback so in an interrupt context. It will deadlock when trying to
> grab the xa_lock which is already held by CPU0.
> 
> Replacing all xa_* usage by their xa_*_irq counterparts would fix
> this issue, but Christian pointed out another issue: dma_fence_signal
> takes fence.lock and so does dma_fence_add_callback.
> 
>   dma_fence_signal() // locks f1.lock
>   -> drm_sched_entity_kill_jobs_cb()
>   -> foreach dependencies
>      -> dma_fence_add_callback() // locks f2.lock
> 
> This will deadlock if f1 and f2 share the same spinlock.
> 
> To fix both issues, the code iterating on dependencies and re-arming them
> is moved out to drm_sched_entity_kill_jobs_work.
> 
> v2: reworded commit message (Philipp)
> v3: added Fixes tag (Philipp)
> 
> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>

Pushed to drm-misc-fixes.

Thx, Pierre-Eric!


P.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-11-05 11:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-04  9:53 [PATCH v3] drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb Pierre-Eric Pelloux-Prayer
2025-11-04 12:43 ` Philipp Stanner
2025-11-04 15:24   ` Pierre-Eric Pelloux-Prayer
2025-11-04 15:30     ` Philipp Stanner
2025-11-04 15:34       ` Pierre-Eric Pelloux-Prayer
2025-11-05 11:32 ` Philipp Stanner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®