On Mon, 2026-09-14 at 20:27 +0200, Christian König wrote: > Tvrkos patches added RCU protection to the returned strings from
*Tvrtko ;) Anyways, which patches? Better add a commit ID? > get_timeline_name()/get_driver_name() callbacks of the dma_fence > backends. > > This fixed use after free problems for a couple of drivers, but we never > documented the consequences for the drm_sched_fence. > > Add a few words on the function documentation to note that we need an > RCU grace period between signaling the last scheduler fence and s/scheduler fence/hardware-fence :D > scheduler teardown. > > Signed-off-by: Christian König <[email protected]> with the above: Acked-by: Philipp Stanner <[email protected]> > --- > drivers/gpu/drm/scheduler/sched_main.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > index 6cb6f95464938..f73c5141b4e5c 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -1203,6 +1203,11 @@ static void drm_sched_cancel_remaining_jobs(struct > drm_gpu_scheduler *sched) > * is implemented, all jobs will be canceled through it and afterwards > cleaned > * up through &struct drm_sched_backend_ops.free_job. If cancel_job is not > * implemented, memory could leak. > + * > + * The user must wait one RCU grace period between signaling the last > hardware- > + * fence and calling this function because the timeline name returned by > + * scheduler fences must stay valid until all readers have exited their RCU > read > + * side critical section. > */ > void drm_sched_fini(struct drm_gpu_scheduler *sched) > {
