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

[Philipp Stanner <phasta@mailbox.org>]

On Wed, 2026-09-02 at 02:57 -0700, 김종혁 wrote:
> On 02/09/2026 10:46, Tvrtko Ursulin wrote:
> > It is not guaranteed in the documented contract that the name passed to
> > drm_sched_init has to outlive the scheduler.
> 
> Right. Caching the bare pointer only works because every in-tree driver
> passes a string literal today - xe's q->name (freed with the exec queue,
> hence 299bc6d50b1b) is the counter-example where v1 would still dangle.
> 
> > Hm, that might be overkill.. how about we just keep a copy of the name
> > in the scheduler object?
> 
> The catch is the scheduler object is itself freed on context teardown, so
> a copy that lives there dangles for the exported fence just the same. To
> actually stop dereferencing ->sched the copy has to live in the fence -
> kstrdup in drm_sched_fence_init(), freed from the fence release. That's an
> alloc per fence on the submit path though.
> 
> If that overhead isn't wanted, the lighter option is to keep the pointer
> and document in gpu_scheduler.h that the drm_sched_init() name must follow
> the dma-fence safe access rules (outlive any exported fence). That matches
> what the already-fixed drivers do and leaves the submit path untouched.
> 
> Either one fixes amdxdna/nouveau/msm in the core. I'd lean to the
> documented-pointer version unless you'd rather pay the kstrdup - let me know
> which and I'll respin as a core-only series (fix + the kunit test).
> 
> Thanks for the 6bd90e700b42/299bc6d50b1b context, that clears up what the
> half-fix missed.


The issue here IMO is that we are discussing working around an issue
that actually stems from dma_fence not being consistently synchronized,
notably because of the ops->release callback being implemented.

ops->release is de facto deprecated, precisely for reasons like these.

If we could get rid of it for sched_fence, dma_fence would take care of
the decoupling of the name callbacks.

So that appears worth investigating from my POV.


P.