Re: [PATCH 2/2] drm/sched: document the RCU dependency

["Christian König" <christian.koenig@amd.com>]

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 <christian.koenig@amd.com>
>> ---
>>  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.