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

[Tvrtko Ursulin]

To collate two replies in one:

On 02/09/2026 11:07, Philipp Stanner wrote:
> 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.

Yes, thank you, it would have to be this then. We definitely do not want 
more allocation at fence init for basically a debug only / logging feature.

> > 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.

I completely agree here but I am just not sure how feasible that would 
be. We may accept to live with the cross-documentation workaround at 
least as a start since even if feasible it could be a lot of work to 
change sched_fence like that.

Regards,

Tvrtko