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.
