Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner <phasta@mailbox.org>]

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 :)