On 9/9/26 15:55, Philipp Stanner wrote: > On Wed, 2026-09-09 at 15:14 +0200, Christian König wrote: >> Tvrkos patches added RCU protection to the returned strings from >> 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 >> scheduler teardown. >> >> Signed-off-by: Christian König <[email protected]> >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c >> index 6cb6f9546493..22103cb07782 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -1203,6 +1203,10 @@ 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 scheduler fences timeline name is returned protected by the signaled >> + * status and RCU, so an RCU grace period is necessary between signaling the >> + * last scheduler fence and tearing down the scheduler who originated it. >> */ > > The API user does not signal a "scheduler fence", typically. Are you > referring to the hardware-fence?
Yes, of course. Signaling the HW fence then causes the scheduler fence to signal as well. > > The user must signal all hardware-fences, which will cause all > finished-fences (which are at the root of the addressed problem) to be > signaled. > > So what you probably want to say is "The user must wait one RCU grace > period between signaling the last hardware-fence and calling this > function because …". k, going to fix that. Thanks, Christian. > > > P.
