On Wed, 2026-09-09 at 09:37 +0900, Jonghyuk Kim(MalHyuk) wrote: > On 08/09/2026 13:07, Philipp Stanner wrote: > > Is this an issue? A fence can only be exported if the scheduler exists. > > The hard rule with dma_fence is that all drivers must signal all of > > them before they tear down the scheduler > > Agreed for the bug at hand - that fence is signaled, so 0001 covers it. > > My point was narrower: nothing enforces the rule. drm_sched_fini() only does > > if (!list_empty(&sched->pending_list)) > dev_warn(sched->dev, "Tearing down scheduler while jobs are > pending!\n"); > > and the one path that would drain the list, drm_sched_cancel_remaining_jobs(), > needs ops->cancel_job, which no driver in current mainline implements - > the only user is the mock scheduler in the KUnit tests. So a driver that > gets it wrong gets a warning, not a stopped teardown. Not an argument > against the hot-fix.
True. The cancel_job() cb is currently the recommended solution (although there was disagreement back then) that Tvrtko and I came up with a while ago. The issue was that drm_sched was designed with no idiomatic solution for handling remaining jobs in sched->pending_list on teardown, which is why all drivers presumably have different solutions. cancel_job() was an attempt at providing an idiomatic solution. It's afaik currently being used by Asahi downstream and was used in Nouveau, but Nouveau doesn't need it / cannot use it for other reasons that have to do with page table cleanup AFAIR. So Nouveau covers it with a waitqueue. We could add it to Nouveau again, but then it would never be called because the waitqueue comes first and needs to stay… So should you see a driver that could make good use of it, I would appreciate if you'd try to add it :)
