Re: drm/sched: run queues freed before the TDR that drm_sched_fini() waits for

[Philipp Stanner <phasta@mailbox.org>]

On Thu, 2026-09-10 at 18:50 +0900, Donggeun Yoo wrote:
> On 9/10/26 10:51, Philipp Stanner wrote:
> > Which KUnit test case exactly?
> 
> A local one. It is not in the tree - I wrote it for this, which is why you
> could not find it. I should have said that explicitly.

OK. For the future please provide the reproducer somehow, for example
through a repo link.

> 
> It is a mock scheduler whose run_job() returns a hardware fence that is
> never signaled,

Alright, so as we agreed on that's then not a bug fix relevant for
upstream.

> 
> Right, that's what my patch does: drm_sched_wqueue_stop(), then
> cancel_delayed_work_sync(&sched->work_tdr), then the frees. The report is
> gone and nothing else in the suite fails.
> 
> As you say, that is closer to a cleanup - or to making the teardown order
> state its intent - than to a fix. Do you still want the reordering patch?

I think it's a good idea. I'd move the deallocations above the related
kfree at the bottom.


What would be more valuable, though, would be a hint in the docu that
the hardware fences must have been signaled before drm_sched_fini() is
called. I thought we had sth like that, but apparently we don't.

@Christian: Could you address this here [1]?


Thanks
P.


[1] https://lore.kernel.org/dri-devel/20260909131808.2201-3-christian.koenig@amd.com/