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.
