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 17:44 +0900, Donggeun Yoo wrote:
> On 9/10/26 09:32, Christian König wrote:
> 
> work_tdr is queued on sched->timeout_wq and is only canceled by the
> cancel_delayed_work_sync() below the loop, so a timeout handler can still
> be running while the run queues are freed.

It is not as obvious to me as it is to you why you think that the
timeout handler is exploding.

> On how I got there: the KUnit case never signals the hardware fence, which

Which KUnit test case exactly?

I kindly asked you to provide more details about how and where the bug
occurs. Can you post a longer stacktrace and also run
scrips/decode_stacktrace.sh on it?

> is what keeps the handler inside timedout_job() while drm_sched_fini() runs.
> That breaks the rule that all run_job() fences are signaled before
> drm_sched_fini(), so a correct driver should not reach this, and I have no
> reproducer that does not cheat that way. The same caveat is in the patch.

If the bug only exists because someone does not signal all hardware-
fences (that's what we call the ones returned from run_job()), then I
tend to think that this is not a scheduler bug.

Maybe a kunit test bug that should be fixed.

Though for robustness reasons we _could_ nevertheless stop the timeout
work item before releasing other resources. But that's just a best-
effort nice-to-have change, since the change making a difference would
mean that there are life time violations with ordering issues anyways.


P.