[PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Lin.Cao]

When application A submits jobs and application B submits a job with a
dependency on A's fence, the normal flow wakes up the scheduler after
processing each job. However, the optimization in
drm_sched_entity_add_dependency_cb() uses a callback that only clears
dependencies without waking up the scheduler.

When application A is killed before its jobs can run, the callback gets
triggered but only clears the dependency without waking up the scheduler,
causing the scheduler to enter sleep state and application B to hang.

Remove the optimization by deleting drm_sched_entity_clear_dep() and its
usage, ensuring the scheduler is always woken up when dependencies are
cleared.

Signed-off-by: Lin.Cao <lincao12@amd.com>
---
 drivers/gpu/drm/scheduler/sched_entity.c | 21 ++-------------------
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
index e671aa241720..ac678de7fe5e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct drm_sched_entity *entity)
 }
 EXPORT_SYMBOL(drm_sched_entity_destroy);
 
-/* drm_sched_entity_clear_dep - callback to clear the entities dependency */
-static void drm_sched_entity_clear_dep(struct dma_fence *f,
-				       struct dma_fence_cb *cb)
-{
-	struct drm_sched_entity *entity =
-		container_of(cb, struct drm_sched_entity, cb);
-
-	entity->dependency = NULL;
-	dma_fence_put(f);
-}
-
 /*
  * drm_sched_entity_wakeup - callback to clear the entity's dependency and
  * wake up the scheduler
@@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct dma_fence *f,
 	struct drm_sched_entity *entity =
 		container_of(cb, struct drm_sched_entity, cb);
 
-	drm_sched_entity_clear_dep(f, cb);
+	entity->dependency = NULL;
+	dma_fence_put(f);
 	drm_sched_wakeup(entity->rq->sched);
 }
 
@@ -429,13 +419,6 @@ static bool drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
 		fence = dma_fence_get(&s_fence->scheduled);
 		dma_fence_put(entity->dependency);
 		entity->dependency = fence;
-		if (!dma_fence_add_callback(fence, &entity->cb,
-					    drm_sched_entity_clear_dep))
-			return true;
-
-		/* Ignore it when it is already scheduled */
-		dma_fence_put(fence);
-		return false;
 	}
 
 	if (!dma_fence_add_callback(entity->dependency, &entity->cb,
-- 
2.46.1

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Christian König]

On 15.07.25 15:50, Lin.Cao wrote:
> When application A submits jobs and application B submits a job with a
> dependency on A's fence, the normal flow wakes up the scheduler after
> processing each job. However, the optimization in
> drm_sched_entity_add_dependency_cb() uses a callback that only clears
> dependencies without waking up the scheduler.
> 
> When application A is killed before its jobs can run, the callback gets
> triggered but only clears the dependency without waking up the scheduler,
> causing the scheduler to enter sleep state and application B to hang.
> 
> Remove the optimization by deleting drm_sched_entity_clear_dep() and its
> usage, ensuring the scheduler is always woken up when dependencies are
> cleared.
> 
> Signed-off-by: Lin.Cao <lincao12@amd.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++-------------------
>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> index e671aa241720..ac678de7fe5e 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct drm_sched_entity *entity)
>  }
>  EXPORT_SYMBOL(drm_sched_entity_destroy);
>  
> -/* drm_sched_entity_clear_dep - callback to clear the entities dependency */
> -static void drm_sched_entity_clear_dep(struct dma_fence *f,
> -				       struct dma_fence_cb *cb)
> -{
> -	struct drm_sched_entity *entity =
> -		container_of(cb, struct drm_sched_entity, cb);
> -
> -	entity->dependency = NULL;
> -	dma_fence_put(f);
> -}
> -
>  /*
>   * drm_sched_entity_wakeup - callback to clear the entity's dependency and
>   * wake up the scheduler
> @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct dma_fence *f,
>  	struct drm_sched_entity *entity =
>  		container_of(cb, struct drm_sched_entity, cb);
>  
> -	drm_sched_entity_clear_dep(f, cb);
> +	entity->dependency = NULL;
> +	dma_fence_put(f);
>  	drm_sched_wakeup(entity->rq->sched);
>  }
>  
> @@ -429,13 +419,6 @@ static bool drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>  		fence = dma_fence_get(&s_fence->scheduled);
>  		dma_fence_put(entity->dependency);
>  		entity->dependency = fence;
> -		if (!dma_fence_add_callback(fence, &entity->cb,
> -					    drm_sched_entity_clear_dep))
> -			return true;
> -
> -		/* Ignore it when it is already scheduled */
> -		dma_fence_put(fence);
> -		return false;
>  	}
>  
>  	if (!dma_fence_add_callback(entity->dependency, &entity->cb,

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Philipp Stanner]

On Tue, 2025-07-15 at 21:50 +0800, Lin.Cao wrote:
> When application A submits jobs and application B submits a job with
> a
> dependency on A's fence, the normal flow wakes up the scheduler after
> processing each job. However, the optimization in
> drm_sched_entity_add_dependency_cb() uses a callback that only clears
> dependencies without waking up the scheduler.
> 
> When application A is killed before its jobs can run, the callback
> gets
> triggered but only clears the dependency without waking up the
> scheduler,
> causing the scheduler to enter sleep state and application B to hang.
> 
> Remove the optimization by deleting drm_sched_entity_clear_dep() and
> its
> usage, ensuring the scheduler is always woken up when dependencies
> are
> cleared.
> 
> Signed-off-by: Lin.Cao <lincao12@amd.com>

This is, still, a bug fix, so it needs Fixes: and Cc: stable :)

Could also include a Suggested-by: Christian

P.

> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++-------------------
>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index e671aa241720..ac678de7fe5e 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct
> drm_sched_entity *entity)
>  }
>  EXPORT_SYMBOL(drm_sched_entity_destroy);
>  
> -/* drm_sched_entity_clear_dep - callback to clear the entities
> dependency */
> -static void drm_sched_entity_clear_dep(struct dma_fence *f,
> -				       struct dma_fence_cb *cb)
> -{
> -	struct drm_sched_entity *entity =
> -		container_of(cb, struct drm_sched_entity, cb);
> -
> -	entity->dependency = NULL;
> -	dma_fence_put(f);
> -}
> -
>  /*
>   * drm_sched_entity_wakeup - callback to clear the entity's
> dependency and
>   * wake up the scheduler
> @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct
> dma_fence *f,
>  	struct drm_sched_entity *entity =
>  		container_of(cb, struct drm_sched_entity, cb);
>  
> -	drm_sched_entity_clear_dep(f, cb);
> +	entity->dependency = NULL;
> +	dma_fence_put(f);
>  	drm_sched_wakeup(entity->rq->sched);
>  }
>  
> @@ -429,13 +419,6 @@ static bool
> drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>  		fence = dma_fence_get(&s_fence->scheduled);
>  		dma_fence_put(entity->dependency);
>  		entity->dependency = fence;
> -		if (!dma_fence_add_callback(fence, &entity->cb,
> -					   
> drm_sched_entity_clear_dep))
> -			return true;
> -
> -		/* Ignore it when it is already scheduled */
> -		dma_fence_put(fence);
> -		return false;
>  	}
>  
>  	if (!dma_fence_add_callback(entity->dependency, &entity->cb,

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[cao, lin]

[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Philipp,

Thank you for the review. I found that this optimization was introduced 9 years ago in commit 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a dummy wakeup scheduler").

Given that the codebase has undergone significant changes over these 9 years. May I ask if I still need to include the Fixes: tag?

Thanks,
Lin
________________________________
From: Philipp Stanner <phasta@mailbox.org>
Sent: Wednesday, July 16, 2025 16:33
To: cao, lin <lin.cao@amd.com>; dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>
Cc: Yin, ZhenGuo (Chris) <ZhenGuo.Yin@amd.com>; Deng, Emily <Emily.Deng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; phasta@kernel.org <phasta@kernel.org>; dakr@kernel.org <dakr@kernel.org>; matthew.brost@intel.com <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

On Tue, 2025-07-15 at 21:50 +0800, Lin.Cao wrote:
> When application A submits jobs and application B submits a job with
> a
> dependency on A's fence, the normal flow wakes up the scheduler after
> processing each job. However, the optimization in
> drm_sched_entity_add_dependency_cb() uses a callback that only clears
> dependencies without waking up the scheduler.
>
> When application A is killed before its jobs can run, the callback
> gets
> triggered but only clears the dependency without waking up the
> scheduler,
> causing the scheduler to enter sleep state and application B to hang.
>
> Remove the optimization by deleting drm_sched_entity_clear_dep() and
> its
> usage, ensuring the scheduler is always woken up when dependencies
> are
> cleared.
>
> Signed-off-by: Lin.Cao <lincao12@amd.com>

This is, still, a bug fix, so it needs Fixes: and Cc: stable :)

Could also include a Suggested-by: Christian

P.

> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++-------------------
>  1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index e671aa241720..ac678de7fe5e 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct
> drm_sched_entity *entity)
>  }
>  EXPORT_SYMBOL(drm_sched_entity_destroy);
>
> -/* drm_sched_entity_clear_dep - callback to clear the entities
> dependency */
> -static void drm_sched_entity_clear_dep(struct dma_fence *f,
> -                                    struct dma_fence_cb *cb)
> -{
> -     struct drm_sched_entity *entity =
> -             container_of(cb, struct drm_sched_entity, cb);
> -
> -     entity->dependency = NULL;
> -     dma_fence_put(f);
> -}
> -
>  /*
>   * drm_sched_entity_wakeup - callback to clear the entity's
> dependency and
>   * wake up the scheduler
> @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct
> dma_fence *f,
>       struct drm_sched_entity *entity =
>               container_of(cb, struct drm_sched_entity, cb);
>
> -     drm_sched_entity_clear_dep(f, cb);
> +     entity->dependency = NULL;
> +     dma_fence_put(f);
>       drm_sched_wakeup(entity->rq->sched);
>  }
>
> @@ -429,13 +419,6 @@ static bool
> drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>               fence = dma_fence_get(&s_fence->scheduled);
>               dma_fence_put(entity->dependency);
>               entity->dependency = fence;
> -             if (!dma_fence_add_callback(fence, &entity->cb,
> -
> drm_sched_entity_clear_dep))
> -                     return true;
> -
> -             /* Ignore it when it is already scheduled */
> -             dma_fence_put(fence);
> -             return false;
>       }
>
>       if (!dma_fence_add_callback(entity->dependency, &entity->cb,


[-- Attachment #2: Type: text/html, Size: 8194 bytes --]

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Christian König]

On 16.07.25 11:43, cao, lin wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> 
> Hi Philipp,
> 
> Thank you for the review. I found that this optimization was introduced 9 years ago in commit 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a dummy wakeup scheduler").
> 
> Given that the codebase has undergone significant changes over these 9 years. May I ask if I still need to include the Fixes: tag?

Most likely not, a CC: stable tag should be sufficient.

Regards,
Christian.

> 
> Thanks,
> Lin
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Philipp Stanner <phasta@mailbox.org>
> *Sent:* Wednesday, July 16, 2025 16:33
> *To:* cao, lin <lin.cao@amd.com>; dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>
> *Cc:* Yin, ZhenGuo (Chris) <ZhenGuo.Yin@amd.com>; Deng, Emily <Emily.Deng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; phasta@kernel.org <phasta@kernel.org>; dakr@kernel.org <dakr@kernel.org>; matthew.brost@intel.com <matthew.brost@intel.com>
> *Subject:* Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs
>  
> On Tue, 2025-07-15 at 21:50 +0800, Lin.Cao wrote:
>> When application A submits jobs and application B submits a job with
>> a
>> dependency on A's fence, the normal flow wakes up the scheduler after
>> processing each job. However, the optimization in
>> drm_sched_entity_add_dependency_cb() uses a callback that only clears
>> dependencies without waking up the scheduler.
>> 
>> When application A is killed before its jobs can run, the callback
>> gets
>> triggered but only clears the dependency without waking up the
>> scheduler,
>> causing the scheduler to enter sleep state and application B to hang.
>> 
>> Remove the optimization by deleting drm_sched_entity_clear_dep() and
>> its
>> usage, ensuring the scheduler is always woken up when dependencies
>> are
>> cleared.
>> 
>> Signed-off-by: Lin.Cao <lincao12@amd.com>
> 
> This is, still, a bug fix, so it needs Fixes: and Cc: stable :)
> 
> Could also include a Suggested-by: Christian
> 
> P.
> 
>> ---
>>  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++-------------------
>>  1 file changed, 2 insertions(+), 19 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
>> b/drivers/gpu/drm/scheduler/sched_entity.c
>> index e671aa241720..ac678de7fe5e 100644
>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>> @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct
>> drm_sched_entity *entity)
>>  }
>>  EXPORT_SYMBOL(drm_sched_entity_destroy);
>>  
>> -/* drm_sched_entity_clear_dep - callback to clear the entities
>> dependency */
>> -static void drm_sched_entity_clear_dep(struct dma_fence *f,
>> -                                    struct dma_fence_cb *cb)
>> -{
>> -     struct drm_sched_entity *entity =
>> -             container_of(cb, struct drm_sched_entity, cb);
>> -
>> -     entity->dependency = NULL;
>> -     dma_fence_put(f);
>> -}
>> -
>>  /*
>>   * drm_sched_entity_wakeup - callback to clear the entity's
>> dependency and
>>   * wake up the scheduler
>> @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct
>> dma_fence *f,
>>       struct drm_sched_entity *entity =
>>               container_of(cb, struct drm_sched_entity, cb);
>>  
>> -     drm_sched_entity_clear_dep(f, cb);
>> +     entity->dependency = NULL;
>> +     dma_fence_put(f);
>>       drm_sched_wakeup(entity->rq->sched);
>>  }
>>  
>> @@ -429,13 +419,6 @@ static bool
>> drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
>>               fence = dma_fence_get(&s_fence->scheduled);
>>               dma_fence_put(entity->dependency);
>>               entity->dependency = fence;
>> -             if (!dma_fence_add_callback(fence, &entity->cb,
>> -                                        
>> drm_sched_entity_clear_dep))
>> -                     return true;
>> -
>> -             /* Ignore it when it is already scheduled */
>> -             dma_fence_put(fence);
>> -             return false;
>>       }
>>  
>>       if (!dma_fence_add_callback(entity->dependency, &entity->cb,
> 

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Philipp Stanner]

On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> 
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> 
> 
> Hi Philipp,
> 
> 
> Thank you for the review. I found that this optimization was
> introduced 9 years ago in commit
> 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a dummy
> wakeup scheduler").
> 
> 
> Given that the codebase has undergone significant changes over these
> 9 years. May I ask if I still need to include the Fixes: tag?

Yes. It's a helpful marker to see where the problem comes from, and it
adds redundancy helping the stable-kernel maintainers in figuring out
to which kernels to backport it to.

If stable can't apply a patch to a very old stable kernel because the
code base changed too much, they'll ping us and we might provide a
dedicated fix.

So like that:

Cc: stable@vger.kernel.org # v4.6+
Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")


P.

> 
> 
> Thanks,
> Lin
> 
> 
> From: Philipp Stanner <phasta@mailbox.org>
> Sent: Wednesday, July 16, 2025 16:33
> To: cao, lin <lin.cao@amd.com>; dri-devel@lists.freedesktop.org
> <dri-devel@lists.freedesktop.org>
> Cc: Yin, ZhenGuo (Chris) <ZhenGuo.Yin@amd.com>; Deng, Emily
> <Emily.Deng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>;
> phasta@kernel.org <phasta@kernel.org>; dakr@kernel.org
> <dakr@kernel.org>; matthew.brost@intel.com <matthew.brost@intel.com>
> Subject: Re: [PATCH] drm/sched: Remove optimization that causes hang
> when killing dependent jobs
> 
>  
> 
> 
> On Tue, 2025-07-15 at 21:50 +0800, Lin.Cao wrote:
> > When application A submits jobs and application B submits a job
> > with
> > a
> > dependency on A's fence, the normal flow wakes up the scheduler
> > after
> > processing each job. However, the optimization in
> > drm_sched_entity_add_dependency_cb() uses a callback that only
> > clears
> > dependencies without waking up the scheduler.
> > 
> > When application A is killed before its jobs can run, the callback
> > gets
> > triggered but only clears the dependency without waking up the
> > scheduler,
> > causing the scheduler to enter sleep state and application B to
> > hang.
> > 
> > Remove the optimization by deleting drm_sched_entity_clear_dep()
> > and
> > its
> > usage, ensuring the scheduler is always woken up when dependencies
> > are
> > cleared.
> > 
> > Signed-off-by: Lin.Cao <lincao12@amd.com>
> 
> This is, still, a bug fix, so it needs Fixes: and Cc: stable :)
> 
> Could also include a Suggested-by: Christian
> 
> P.
> 
> > ---
> >  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++------------------
> > -
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> > b/drivers/gpu/drm/scheduler/sched_entity.c
> > index e671aa241720..ac678de7fe5e 100644
> > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct
> > drm_sched_entity *entity)
> >  }
> >  EXPORT_SYMBOL(drm_sched_entity_destroy);
> >  
> > -/* drm_sched_entity_clear_dep - callback to clear the entities
> > dependency */
> > -static void drm_sched_entity_clear_dep(struct dma_fence *f,
> > -                                    struct dma_fence_cb *cb)
> > -{
> > -     struct drm_sched_entity *entity =
> > -             container_of(cb, struct drm_sched_entity, cb);
> > -
> > -     entity->dependency = NULL;
> > -     dma_fence_put(f);
> > -}
> > -
> >  /*
> >   * drm_sched_entity_wakeup - callback to clear the entity's
> > dependency and
> >   * wake up the scheduler
> > @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct
> > dma_fence *f,
> >       struct drm_sched_entity *entity =
> >               container_of(cb, struct drm_sched_entity, cb);
> >  
> > -     drm_sched_entity_clear_dep(f, cb);
> > +     entity->dependency = NULL;
> > +     dma_fence_put(f);
> >       drm_sched_wakeup(entity->rq->sched);
> >  }
> >  
> > @@ -429,13 +419,6 @@ static bool
> > drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
> >               fence = dma_fence_get(&s_fence->scheduled);
> >               dma_fence_put(entity->dependency);
> >               entity->dependency = fence;
> > -             if (!dma_fence_add_callback(fence, &entity->cb,
> > -                                        
> > drm_sched_entity_clear_dep))
> > -                     return true;
> > -
> > -             /* Ignore it when it is already scheduled */
> > -             dma_fence_put(fence);
> > -             return false;
> >       }
> >  
> >       if (!dma_fence_add_callback(entity->dependency, &entity->cb,
> 

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[cao, lin]

[-- Attachment #1: Type: text/plain, Size: 6418 bytes --]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Philipp, Christian,

I modified the commit msg as:

drm/sched: Remove optimization that causes hang when killing dependent jobs

When application A submits jobs and application B submits a job with a
dependency on A's fence, the normal flow wakes up the scheduler after
processing each job. However, the optimization in
drm_sched_entity_add_dependency_cb() uses a callback that only clears
dependencies without waking up the scheduler.

When application A is killed before its jobs can run, the callback gets
triggered but only clears the dependency without waking up the scheduler,
causing the scheduler to enter sleep state and application B to hang.

Remove the optimization by deleting drm_sched_entity_clear_dep() and its
usage, ensuring the scheduler is always woken up when dependencies are
cleared.

Cc: stable@vger.kernel.org # v4.6+
Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
Suggested-by: Christian König <Christian.Koenig@amd.com>
Signed-off-by: Lin.Cao <lincao12@amd.com>

Thanks,
Lin


________________________________
From: Philipp Stanner <phasta@mailbox.org>
Sent: Wednesday, July 16, 2025 17:57
To: cao, lin <lin.cao@amd.com>; dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>; phasta@kernel.org <phasta@kernel.org>
Cc: Yin, ZhenGuo (Chris) <ZhenGuo.Yin@amd.com>; Deng, Emily <Emily.Deng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; dakr@kernel.org <dakr@kernel.org>; matthew.brost@intel.com <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
>
>
> Hi Philipp,
>
>
> Thank you for the review. I found that this optimization was
> introduced 9 years ago in commit
> 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a dummy
> wakeup scheduler").
>
>
> Given that the codebase has undergone significant changes over these
> 9 years. May I ask if I still need to include the Fixes: tag?

Yes. It's a helpful marker to see where the problem comes from, and it
adds redundancy helping the stable-kernel maintainers in figuring out
to which kernels to backport it to.

If stable can't apply a patch to a very old stable kernel because the
code base changed too much, they'll ping us and we might provide a
dedicated fix.

So like that:

Cc: stable@vger.kernel.org # v4.6+
Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")


P.

>
>
> Thanks,
> Lin
>
>
> From: Philipp Stanner <phasta@mailbox.org>
> Sent: Wednesday, July 16, 2025 16:33
> To: cao, lin <lin.cao@amd.com>; dri-devel@lists.freedesktop.org
> <dri-devel@lists.freedesktop.org>
> Cc: Yin, ZhenGuo (Chris) <ZhenGuo.Yin@amd.com>; Deng, Emily
> <Emily.Deng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>;
> phasta@kernel.org <phasta@kernel.org>; dakr@kernel.org
> <dakr@kernel.org>; matthew.brost@intel.com <matthew.brost@intel.com>
> Subject: Re: [PATCH] drm/sched: Remove optimization that causes hang
> when killing dependent jobs
>
>
>
>
> On Tue, 2025-07-15 at 21:50 +0800, Lin.Cao wrote:
> > When application A submits jobs and application B submits a job
> > with
> > a
> > dependency on A's fence, the normal flow wakes up the scheduler
> > after
> > processing each job. However, the optimization in
> > drm_sched_entity_add_dependency_cb() uses a callback that only
> > clears
> > dependencies without waking up the scheduler.
> >
> > When application A is killed before its jobs can run, the callback
> > gets
> > triggered but only clears the dependency without waking up the
> > scheduler,
> > causing the scheduler to enter sleep state and application B to
> > hang.
> >
> > Remove the optimization by deleting drm_sched_entity_clear_dep()
> > and
> > its
> > usage, ensuring the scheduler is always woken up when dependencies
> > are
> > cleared.
> >
> > Signed-off-by: Lin.Cao <lincao12@amd.com>
>
> This is, still, a bug fix, so it needs Fixes: and Cc: stable :)
>
> Could also include a Suggested-by: Christian
>
> P.
>
> > ---
> >  drivers/gpu/drm/scheduler/sched_entity.c | 21 ++------------------
> > -
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> > b/drivers/gpu/drm/scheduler/sched_entity.c
> > index e671aa241720..ac678de7fe5e 100644
> > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct
> > drm_sched_entity *entity)
> >  }
> >  EXPORT_SYMBOL(drm_sched_entity_destroy);
> >
> > -/* drm_sched_entity_clear_dep - callback to clear the entities
> > dependency */
> > -static void drm_sched_entity_clear_dep(struct dma_fence *f,
> > -                                    struct dma_fence_cb *cb)
> > -{
> > -     struct drm_sched_entity *entity =
> > -             container_of(cb, struct drm_sched_entity, cb);
> > -
> > -     entity->dependency = NULL;
> > -     dma_fence_put(f);
> > -}
> > -
> >  /*
> >   * drm_sched_entity_wakeup - callback to clear the entity's
> > dependency and
> >   * wake up the scheduler
> > @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct
> > dma_fence *f,
> >       struct drm_sched_entity *entity =
> >               container_of(cb, struct drm_sched_entity, cb);
> >
> > -     drm_sched_entity_clear_dep(f, cb);
> > +     entity->dependency = NULL;
> > +     dma_fence_put(f);
> >       drm_sched_wakeup(entity->rq->sched);
> >  }
> >
> > @@ -429,13 +419,6 @@ static bool
> > drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity)
> >               fence = dma_fence_get(&s_fence->scheduled);
> >               dma_fence_put(entity->dependency);
> >               entity->dependency = fence;
> > -             if (!dma_fence_add_callback(fence, &entity->cb,
> > -
> > drm_sched_entity_clear_dep))
> > -                     return true;
> > -
> > -             /* Ignore it when it is already scheduled */
> > -             dma_fence_put(fence);
> > -             return false;
> >       }
> >
> >       if (!dma_fence_add_callback(entity->dependency, &entity->cb,
>


[-- Attachment #2: Type: text/html, Size: 15295 bytes --]

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Danilo Krummrich]

On Wed Jul 16, 2025 at 12:05 PM CEST, lin cao wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]

Two small off-topic remarks from my side. :)

Can you please remove "AMD Official Use Only" header when sending to public
mailing lists? Otherwise people may have to delete your mails unread.

Please try to avoid top-post replies [1].

Thanks!

- Danilo

[1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Michel Dänzer]

On 16.07.25 11:57, Philipp Stanner wrote:
> On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
>>
>> Hi Philipp,
>>
>>
>> Thank you for the review. I found that this optimization was
>> introduced 9 years ago in commit
>> 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a dummy
>> wakeup scheduler").
>>
>>
>> Given that the codebase has undergone significant changes over these
>> 9 years. May I ask if I still need to include the Fixes: tag?
> 
> Yes. It's a helpful marker to see where the problem comes from, and it
> adds redundancy helping the stable-kernel maintainers in figuring out
> to which kernels to backport it to.
> 
> If stable can't apply a patch to a very old stable kernel because the
> code base changed too much, they'll ping us and we might provide a
> dedicated fix.
> 
> So like that:
> 
> Cc: stable@vger.kernel.org # v4.6+
> Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")

FWIW, Fixes: alone is enough for getting backported to stable branches, Cc: stable is redundant with it.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Christian König]

On 16.07.25 12:13, Danilo Krummrich wrote:
> On Wed Jul 16, 2025 at 12:05 PM CEST, lin cao wrote:
>> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Two small off-topic remarks from my side. :)
> 
> Can you please remove "AMD Official Use Only" header when sending to public
> mailing lists? Otherwise people may have to delete your mails unread.

It's automatically added by the mail client/server.

But for some reason this automation doesn't work correctly since Lin is clearly sending to a public mailing list.

It took me actually quite some effort to convince IT about having an exception on it.

Going to talk with my manager and IT about it once more when I have a chance.

Regards,
Christian.


> Please try to avoid top-post replies [1].
> 
> Thanks!
> 
> - Danilo
> 
> [1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Philipp Stanner]

+Cc Greg, Sasha

On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> On 16.07.25 11:57, Philipp Stanner wrote:
> > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > 
> > > Hi Philipp,
> > > 
> > > 
> > > Thank you for the review. I found that this optimization was
> > > introduced 9 years ago in commit
> > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a
> > > dummy
> > > wakeup scheduler").
> > > 
> > > 
> > > Given that the codebase has undergone significant changes over
> > > these
> > > 9 years. May I ask if I still need to include the Fixes: tag?
> > 
> > Yes. It's a helpful marker to see where the problem comes from, and
> > it
> > adds redundancy helping the stable-kernel maintainers in figuring
> > out
> > to which kernels to backport it to.
> > 
> > If stable can't apply a patch to a very old stable kernel because
> > the
> > code base changed too much, they'll ping us and we might provide a
> > dedicated fix.
> > 
> > So like that:
> > 
> > Cc: stable@vger.kernel.org # v4.6+
> > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
> 
> FWIW, Fixes: alone is enough for getting backported to stable
> branches, Cc: stable is redundant with it.

Both are used all the time together, though. And the official
documentation does not list dropping Cc: stable as a valid option in
this regard

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1


As long as the official documentation demands it, I'm not willing to
drop it. If the docu were to be changed, that would be fine by me, too.


P.


> 
> 

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Christian König]

On 16.07.25 12:46, Philipp Stanner wrote:
> +Cc Greg, Sasha
> 
> On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
>> On 16.07.25 11:57, Philipp Stanner wrote:
>>> On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
>>>>
>>>> Hi Philipp,
>>>>
>>>>
>>>> Thank you for the review. I found that this optimization was
>>>> introduced 9 years ago in commit
>>>> 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a
>>>> dummy
>>>> wakeup scheduler").
>>>>
>>>>
>>>> Given that the codebase has undergone significant changes over
>>>> these
>>>> 9 years. May I ask if I still need to include the Fixes: tag?
>>>
>>> Yes. It's a helpful marker to see where the problem comes from, and
>>> it
>>> adds redundancy helping the stable-kernel maintainers in figuring
>>> out
>>> to which kernels to backport it to.
>>>
>>> If stable can't apply a patch to a very old stable kernel because
>>> the
>>> code base changed too much, they'll ping us and we might provide a
>>> dedicated fix.
>>>
>>> So like that:
>>>
>>> Cc: stable@vger.kernel.org # v4.6+
>>> Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
>>
>> FWIW, Fixes: alone is enough for getting backported to stable
>> branches, Cc: stable is redundant with it.
> 
> Both are used all the time together, though. And the official
> documentation does not list dropping Cc: stable as a valid option in
> this regard
> 
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> 
> 
> As long as the official documentation demands it, I'm not willing to
> drop it. If the docu were to be changed, that would be fine by me, too.

As far as I understand "CC: stable" and "Fixes:" tags are to handle two distinct use cases.

"CC: stable..." means please backport, eventually with a kernel version and/or necessary pre-requisites.

"Fixes:" only backport if you have this patch in your tree as well. In other words it is a restriction when to backport something.

Would be nice if somebody could clarify if my understanding here is accurate.

Regards,
Christian.

> 
> 
> P.
> 
> 
>>
>>
> 

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Greg Kroah-Hartman]

On Wed, Jul 16, 2025 at 12:58:28PM +0200, Christian König wrote:
> On 16.07.25 12:46, Philipp Stanner wrote:
> > +Cc Greg, Sasha
> > 
> > On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> >> On 16.07.25 11:57, Philipp Stanner wrote:
> >>> On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> >>>>
> >>>> Hi Philipp,
> >>>>
> >>>>
> >>>> Thank you for the review. I found that this optimization was
> >>>> introduced 9 years ago in commit
> >>>> 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a
> >>>> dummy
> >>>> wakeup scheduler").
> >>>>
> >>>>
> >>>> Given that the codebase has undergone significant changes over
> >>>> these
> >>>> 9 years. May I ask if I still need to include the Fixes: tag?
> >>>
> >>> Yes. It's a helpful marker to see where the problem comes from, and
> >>> it
> >>> adds redundancy helping the stable-kernel maintainers in figuring
> >>> out
> >>> to which kernels to backport it to.
> >>>
> >>> If stable can't apply a patch to a very old stable kernel because
> >>> the
> >>> code base changed too much, they'll ping us and we might provide a
> >>> dedicated fix.
> >>>
> >>> So like that:
> >>>
> >>> Cc: stable@vger.kernel.org # v4.6+
> >>> Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
> >>
> >> FWIW, Fixes: alone is enough for getting backported to stable
> >> branches, Cc: stable is redundant with it.
> > 
> > Both are used all the time together, though. And the official
> > documentation does not list dropping Cc: stable as a valid option in
> > this regard
> > 
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> > 
> > 
> > As long as the official documentation demands it, I'm not willing to
> > drop it. If the docu were to be changed, that would be fine by me, too.
> 
> As far as I understand "CC: stable" and "Fixes:" tags are to handle two distinct use cases.

Yes.

> "CC: stable..." means please backport, eventually with a kernel version and/or necessary pre-requisites.

Yes.

> "Fixes:" only backport if you have this patch in your tree as well. In other words it is a restriction when to backport something.

No.

"Fixes:" is only for you to say "this commit fixes this other commit".
And when you add a cc: stable, that will get you a FAILED email if the
commit does NOT apply that far back.

"Fixes:" on its own does NOT mean it will ever be backported to the
stable trees.  But because so many people KEEP GETTING THIS WRONG
(despite cc: stable@ happening first in history _before_ Fixes: came
about), we do try to sweep the tree every so often and do a "best
effort" backport of those only marked with Fixes:

But that happens later, if at all, and you do NOT get a FAILED email if
a patch does not apply to a stable branch.

So ALWAYS use cc: stable@ for something you want backported to stable
kernels.  That's what the documentation states, and is what we have been
doing for 15+ years now (is it 20?).

thanks,

greg k-h

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Greg Kroah-Hartman]

On Wed, Jul 16, 2025 at 12:46:21PM +0200, Philipp Stanner wrote:
> +Cc Greg, Sasha
> 
> On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> > On 16.07.25 11:57, Philipp Stanner wrote:
> > > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > > 
> > > > Hi Philipp,
> > > > 
> > > > 
> > > > Thank you for the review. I found that this optimization was
> > > > introduced 9 years ago in commit
> > > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop a
> > > > dummy
> > > > wakeup scheduler").
> > > > 
> > > > 
> > > > Given that the codebase has undergone significant changes over
> > > > these
> > > > 9 years. May I ask if I still need to include the Fixes: tag?
> > > 
> > > Yes. It's a helpful marker to see where the problem comes from, and
> > > it
> > > adds redundancy helping the stable-kernel maintainers in figuring
> > > out
> > > to which kernels to backport it to.
> > > 
> > > If stable can't apply a patch to a very old stable kernel because
> > > the
> > > code base changed too much, they'll ping us and we might provide a
> > > dedicated fix.
> > > 
> > > So like that:
> > > 
> > > Cc: stable@vger.kernel.org # v4.6+
> > > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
> > 
> > FWIW, Fixes: alone is enough for getting backported to stable
> > branches, Cc: stable is redundant with it.

As stated later in this thread, this is NOT TRUE AT ALL.

Always explicitly tag things for stable with "cc: stable" for stuff you
want to go to the stable trees.  If you only use "Fixes:" there is no
such guarantee at all.

That goes doubly for the drm trees, where we have a hard enough time
applying the cc: stable@ patches that you all double-commit to different
branches, and we dread every time we see it happen...

thanks,

greg k-h

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Philipp Stanner]

On Wed, 2025-07-16 at 13:15 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 16, 2025 at 12:58:28PM +0200, Christian König wrote:
> > On 16.07.25 12:46, Philipp Stanner wrote:
> > > +Cc Greg, Sasha
> > > 
> > > On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> > > > On 16.07.25 11:57, Philipp Stanner wrote:
> > > > > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > > > > 
> > > > > > Hi Philipp,
> > > > > > 
> > > > > > 
> > > > > > Thank you for the review. I found that this optimization
> > > > > > was
> > > > > > introduced 9 years ago in commit
> > > > > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop
> > > > > > a
> > > > > > dummy
> > > > > > wakeup scheduler").
> > > > > > 
> > > > > > 
> > > > > > Given that the codebase has undergone significant changes
> > > > > > over
> > > > > > these
> > > > > > 9 years. May I ask if I still need to include the Fixes:
> > > > > > tag?
> > > > > 
> > > > > Yes. It's a helpful marker to see where the problem comes
> > > > > from, and
> > > > > it
> > > > > adds redundancy helping the stable-kernel maintainers in
> > > > > figuring
> > > > > out
> > > > > to which kernels to backport it to.
> > > > > 
> > > > > If stable can't apply a patch to a very old stable kernel
> > > > > because
> > > > > the
> > > > > code base changed too much, they'll ping us and we might
> > > > > provide a
> > > > > dedicated fix.
> > > > > 
> > > > > So like that:
> > > > > 
> > > > > Cc: stable@vger.kernel.org # v4.6+
> > > > > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup
> > > > > scheduler")
> > > > 
> > > > FWIW, Fixes: alone is enough for getting backported to stable
> > > > branches, Cc: stable is redundant with it.
> > > 
> > > Both are used all the time together, though. And the official
> > > documentation does not list dropping Cc: stable as a valid option
> > > in
> > > this regard
> > > 
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> > > 
> > > 
> > > As long as the official documentation demands it, I'm not willing
> > > to
> > > drop it. If the docu were to be changed, that would be fine by
> > > me, too.
> > 
> > As far as I understand "CC: stable" and "Fixes:" tags are to handle
> > two distinct use cases.
> 
> Yes.
> 
> > "CC: stable..." means please backport, eventually with a kernel
> > version and/or necessary pre-requisites.
> 
> Yes.
> 
> > "Fixes:" only backport if you have this patch in your tree as well.
> > In other words it is a restriction when to backport something.
> 
> No.
> 
> "Fixes:" is only for you to say "this commit fixes this other
> commit".
> And when you add a cc: stable, that will get you a FAILED email if
> the
> commit does NOT apply that far back.

Does that mean we should NOT add Fixes: if the fixing patch does not
apply on top of that old commit?

And if so, should we drop the Fixes: tag completely in such cases as
Lin suggested in this thread?


P.

> 
> "Fixes:" on its own does NOT mean it will ever be backported to the
> stable trees.  But because so many people KEEP GETTING THIS WRONG
> (despite cc: stable@ happening first in history _before_ Fixes: came
> about), we do try to sweep the tree every so often and do a "best
> effort" backport of those only marked with Fixes:
> 
> But that happens later, if at all, and you do NOT get a FAILED email
> if
> a patch does not apply to a stable branch.
> 
> So ALWAYS use cc: stable@ for something you want backported to stable
> kernels.  That's what the documentation states, and is what we have
> been
> doing for 15+ years now (is it 20?).
> 
> thanks,
> 
> greg k-h

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Greg Kroah-Hartman]

On Wed, Jul 16, 2025 at 01:32:42PM +0200, Philipp Stanner wrote:
> On Wed, 2025-07-16 at 13:15 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 16, 2025 at 12:58:28PM +0200, Christian König wrote:
> > > On 16.07.25 12:46, Philipp Stanner wrote:
> > > > +Cc Greg, Sasha
> > > > 
> > > > On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> > > > > On 16.07.25 11:57, Philipp Stanner wrote:
> > > > > > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > > > > > 
> > > > > > > Hi Philipp,
> > > > > > > 
> > > > > > > 
> > > > > > > Thank you for the review. I found that this optimization
> > > > > > > was
> > > > > > > introduced 9 years ago in commit
> > > > > > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu: drop
> > > > > > > a
> > > > > > > dummy
> > > > > > > wakeup scheduler").
> > > > > > > 
> > > > > > > 
> > > > > > > Given that the codebase has undergone significant changes
> > > > > > > over
> > > > > > > these
> > > > > > > 9 years. May I ask if I still need to include the Fixes:
> > > > > > > tag?
> > > > > > 
> > > > > > Yes. It's a helpful marker to see where the problem comes
> > > > > > from, and
> > > > > > it
> > > > > > adds redundancy helping the stable-kernel maintainers in
> > > > > > figuring
> > > > > > out
> > > > > > to which kernels to backport it to.
> > > > > > 
> > > > > > If stable can't apply a patch to a very old stable kernel
> > > > > > because
> > > > > > the
> > > > > > code base changed too much, they'll ping us and we might
> > > > > > provide a
> > > > > > dedicated fix.
> > > > > > 
> > > > > > So like that:
> > > > > > 
> > > > > > Cc: stable@vger.kernel.org # v4.6+
> > > > > > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup
> > > > > > scheduler")
> > > > > 
> > > > > FWIW, Fixes: alone is enough for getting backported to stable
> > > > > branches, Cc: stable is redundant with it.
> > > > 
> > > > Both are used all the time together, though. And the official
> > > > documentation does not list dropping Cc: stable as a valid option
> > > > in
> > > > this regard
> > > > 
> > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> > > > 
> > > > 
> > > > As long as the official documentation demands it, I'm not willing
> > > > to
> > > > drop it. If the docu were to be changed, that would be fine by
> > > > me, too.
> > > 
> > > As far as I understand "CC: stable" and "Fixes:" tags are to handle
> > > two distinct use cases.
> > 
> > Yes.
> > 
> > > "CC: stable..." means please backport, eventually with a kernel
> > > version and/or necessary pre-requisites.
> > 
> > Yes.
> > 
> > > "Fixes:" only backport if you have this patch in your tree as well.
> > > In other words it is a restriction when to backport something.
> > 
> > No.
> > 
> > "Fixes:" is only for you to say "this commit fixes this other
> > commit".
> > And when you add a cc: stable, that will get you a FAILED email if
> > the
> > commit does NOT apply that far back.
> 
> Does that mean we should NOT add Fixes: if the fixing patch does not
> apply on top of that old commit?

Add Fixes: if you feel it accurataly describes the commit that caused
the problem that this commit is fixing.  That is independant of "you
need other commits after that to apply this one", that issue can be
resolved by reading the stable kernel rules document and following what
it says there to do for that.

> And if so, should we drop the Fixes: tag completely in such cases as
> Lin suggested in this thread?

If you don't want to ever be notified of any failures of stable patches
being applied as far back as they should be applied, sure, don't put a
Fixes: tag.  That means I do a "best effort" and just stop applying when
they don't apply anymore.

It also means that if you do NOT have a Fixes: tag, and the commit ends
up getting assigned a CVE, we have to assume that the bug has been there
since "the beginning of time" and will mark it as such.  Which might
cause you headaches if you are responsible for keeping older kernels
alive for vendors :)

your call.

hope this helps, and really, this should all be documented already,
right?  If not, what is missing (becides the CVE stuff.)

thanks,

greg k-h

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Philipp Stanner]

On Wed, 2025-07-16 at 14:05 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 16, 2025 at 01:32:42PM +0200, Philipp Stanner wrote:
> > On Wed, 2025-07-16 at 13:15 +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 16, 2025 at 12:58:28PM +0200, Christian König wrote:
> > > > On 16.07.25 12:46, Philipp Stanner wrote:
> > > > > +Cc Greg, Sasha
> > > > > 
> > > > > On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> > > > > > On 16.07.25 11:57, Philipp Stanner wrote:
> > > > > > > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > > > > > > 
> > > > > > > > Hi Philipp,
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Thank you for the review. I found that this
> > > > > > > > optimization
> > > > > > > > was
> > > > > > > > introduced 9 years ago in commit
> > > > > > > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu:
> > > > > > > > drop
> > > > > > > > a
> > > > > > > > dummy
> > > > > > > > wakeup scheduler").
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Given that the codebase has undergone significant
> > > > > > > > changes
> > > > > > > > over
> > > > > > > > these
> > > > > > > > 9 years. May I ask if I still need to include the
> > > > > > > > Fixes:
> > > > > > > > tag?
> > > > > > > 
> > > > > > > Yes. It's a helpful marker to see where the problem comes
> > > > > > > from, and
> > > > > > > it
> > > > > > > adds redundancy helping the stable-kernel maintainers in
> > > > > > > figuring
> > > > > > > out
> > > > > > > to which kernels to backport it to.
> > > > > > > 
> > > > > > > If stable can't apply a patch to a very old stable kernel
> > > > > > > because
> > > > > > > the
> > > > > > > code base changed too much, they'll ping us and we might
> > > > > > > provide a
> > > > > > > dedicated fix.
> > > > > > > 
> > > > > > > So like that:
> > > > > > > 
> > > > > > > Cc: stable@vger.kernel.org # v4.6+
> > > > > > > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup
> > > > > > > scheduler")
> > > > > > 
> > > > > > FWIW, Fixes: alone is enough for getting backported to
> > > > > > stable
> > > > > > branches, Cc: stable is redundant with it.
> > > > > 
> > > > > Both are used all the time together, though. And the official
> > > > > documentation does not list dropping Cc: stable as a valid
> > > > > option
> > > > > in
> > > > > this regard
> > > > > 
> > > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> > > > > 
> > > > > 
> > > > > As long as the official documentation demands it, I'm not
> > > > > willing
> > > > > to
> > > > > drop it. If the docu were to be changed, that would be fine
> > > > > by
> > > > > me, too.
> > > > 
> > > > As far as I understand "CC: stable" and "Fixes:" tags are to
> > > > handle
> > > > two distinct use cases.
> > > 
> > > Yes.
> > > 
> > > > "CC: stable..." means please backport, eventually with a kernel
> > > > version and/or necessary pre-requisites.
> > > 
> > > Yes.
> > > 
> > > > "Fixes:" only backport if you have this patch in your tree as
> > > > well.
> > > > In other words it is a restriction when to backport something.
> > > 
> > > No.
> > > 
> > > "Fixes:" is only for you to say "this commit fixes this other
> > > commit".
> > > And when you add a cc: stable, that will get you a FAILED email
> > > if
> > > the
> > > commit does NOT apply that far back.
> > 
> > Does that mean we should NOT add Fixes: if the fixing patch does
> > not
> > apply on top of that old commit?
> 
> Add Fixes: if you feel it accurataly describes the commit that caused
> the problem that this commit is fixing.  That is independant of "you
> need other commits after that to apply this one", that issue can be
> resolved by reading the stable kernel rules document and following
> what
> it says there to do for that.
> 
> > And if so, should we drop the Fixes: tag completely in such cases
> > as
> > Lin suggested in this thread?
> 
> If you don't want to ever be notified of any failures of stable
> patches
> being applied as far back as they should be applied, sure, don't put
> a
> Fixes: tag.  That means I do a "best effort" and just stop applying
> when
> they don't apply anymore.
> 
> It also means that if you do NOT have a Fixes: tag, and the commit
> ends
> up getting assigned a CVE, we have to assume that the bug has been
> there
> since "the beginning of time" and will mark it as such.  Which might
> cause you headaches if you are responsible for keeping older kernels
> alive for vendors :)
> 
> your call.
> 
> hope this helps, and really, this should all be documented already,
> right?  If not, what is missing (becides the CVE stuff.)

It does help, thank you.

Regarding documentation, I can only tell you that the stable kernel
docu only sparringly mentions the Fixes: tag and it certainly doesn't
mention what you detail above.

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

I think such questions are an excellent example for an FAQ section

"
FAQ

1. Do patches for the stable kernel have to include a Fixes: tag?
"


P.

> 
> thanks,
> 
> greg k-h

Re: [PATCH] drm/sched: Remove optimization that causes hang when killing dependent jobs

[Greg Kroah-Hartman]

On Wed, Jul 16, 2025 at 04:11:27PM +0200, Philipp Stanner wrote:
> On Wed, 2025-07-16 at 14:05 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 16, 2025 at 01:32:42PM +0200, Philipp Stanner wrote:
> > > On Wed, 2025-07-16 at 13:15 +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Jul 16, 2025 at 12:58:28PM +0200, Christian König wrote:
> > > > > On 16.07.25 12:46, Philipp Stanner wrote:
> > > > > > +Cc Greg, Sasha
> > > > > > 
> > > > > > On Wed, 2025-07-16 at 12:40 +0200, Michel Dänzer wrote:
> > > > > > > On 16.07.25 11:57, Philipp Stanner wrote:
> > > > > > > > On Wed, 2025-07-16 at 09:43 +0000, cao, lin wrote:
> > > > > > > > > 
> > > > > > > > > Hi Philipp,
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thank you for the review. I found that this
> > > > > > > > > optimization
> > > > > > > > > was
> > > > > > > > > introduced 9 years ago in commit
> > > > > > > > > 777dbd458c89d4ca74a659f85ffb5bc817f29a35 ("drm/amdgpu:
> > > > > > > > > drop
> > > > > > > > > a
> > > > > > > > > dummy
> > > > > > > > > wakeup scheduler").
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Given that the codebase has undergone significant
> > > > > > > > > changes
> > > > > > > > > over
> > > > > > > > > these
> > > > > > > > > 9 years. May I ask if I still need to include the
> > > > > > > > > Fixes:
> > > > > > > > > tag?
> > > > > > > > 
> > > > > > > > Yes. It's a helpful marker to see where the problem comes
> > > > > > > > from, and
> > > > > > > > it
> > > > > > > > adds redundancy helping the stable-kernel maintainers in
> > > > > > > > figuring
> > > > > > > > out
> > > > > > > > to which kernels to backport it to.
> > > > > > > > 
> > > > > > > > If stable can't apply a patch to a very old stable kernel
> > > > > > > > because
> > > > > > > > the
> > > > > > > > code base changed too much, they'll ping us and we might
> > > > > > > > provide a
> > > > > > > > dedicated fix.
> > > > > > > > 
> > > > > > > > So like that:
> > > > > > > > 
> > > > > > > > Cc: stable@vger.kernel.org # v4.6+
> > > > > > > > Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup
> > > > > > > > scheduler")
> > > > > > > 
> > > > > > > FWIW, Fixes: alone is enough for getting backported to
> > > > > > > stable
> > > > > > > branches, Cc: stable is redundant with it.
> > > > > > 
> > > > > > Both are used all the time together, though. And the official
> > > > > > documentation does not list dropping Cc: stable as a valid
> > > > > > option
> > > > > > in
> > > > > > this regard
> > > > > > 
> > > > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
> > > > > > 
> > > > > > 
> > > > > > As long as the official documentation demands it, I'm not
> > > > > > willing
> > > > > > to
> > > > > > drop it. If the docu were to be changed, that would be fine
> > > > > > by
> > > > > > me, too.
> > > > > 
> > > > > As far as I understand "CC: stable" and "Fixes:" tags are to
> > > > > handle
> > > > > two distinct use cases.
> > > > 
> > > > Yes.
> > > > 
> > > > > "CC: stable..." means please backport, eventually with a kernel
> > > > > version and/or necessary pre-requisites.
> > > > 
> > > > Yes.
> > > > 
> > > > > "Fixes:" only backport if you have this patch in your tree as
> > > > > well.
> > > > > In other words it is a restriction when to backport something.
> > > > 
> > > > No.
> > > > 
> > > > "Fixes:" is only for you to say "this commit fixes this other
> > > > commit".
> > > > And when you add a cc: stable, that will get you a FAILED email
> > > > if
> > > > the
> > > > commit does NOT apply that far back.
> > > 
> > > Does that mean we should NOT add Fixes: if the fixing patch does
> > > not
> > > apply on top of that old commit?
> > 
> > Add Fixes: if you feel it accurataly describes the commit that caused
> > the problem that this commit is fixing.  That is independant of "you
> > need other commits after that to apply this one", that issue can be
> > resolved by reading the stable kernel rules document and following
> > what
> > it says there to do for that.
> > 
> > > And if so, should we drop the Fixes: tag completely in such cases
> > > as
> > > Lin suggested in this thread?
> > 
> > If you don't want to ever be notified of any failures of stable
> > patches
> > being applied as far back as they should be applied, sure, don't put
> > a
> > Fixes: tag.  That means I do a "best effort" and just stop applying
> > when
> > they don't apply anymore.
> > 
> > It also means that if you do NOT have a Fixes: tag, and the commit
> > ends
> > up getting assigned a CVE, we have to assume that the bug has been
> > there
> > since "the beginning of time" and will mark it as such.  Which might
> > cause you headaches if you are responsible for keeping older kernels
> > alive for vendors :)
> > 
> > your call.
> > 
> > hope this helps, and really, this should all be documented already,
> > right?  If not, what is missing (becides the CVE stuff.)
> 
> It does help, thank you.
> 
> Regarding documentation, I can only tell you that the stable kernel
> docu only sparringly mentions the Fixes: tag and it certainly doesn't
> mention what you detail above.
> 
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Yes, it does not mention Fixes: because that's not the way to get a
patch applied to the stable trees.

It says, in plain words:

	Option 1

	To have a patch you submit for mainline inclusion later
	automatically picked up for stable trees, add this tag in the
	sign-off area:
		Cc: stable@vger.kernel.org

Simple, complete, and correct, what more do you want?  :)

thanks,

greg k-h