[PATCH] drm/scheduler: Add missing RCU flag to fence slab

[Christian König]

Am 11.07.23 um 16:49 schrieb Rob Clark:
> On Tue, Jul 11, 2023 at 12:46 AM Christian König
> <christian.koenig at amd.com> wrote:
>> [SNIP]
>>>> ---
>>>>    drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
>>>> index ef120475e7c6..b624711c6e03 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_fence.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
>>>> @@ -35,7 +35,7 @@ static int __init drm_sched_fence_slab_init(void)
>>>>    {
>>>>       sched_fence_slab = kmem_cache_create(
>>>>               "drm_sched_fence", sizeof(struct drm_sched_fence), 0,
>>>> -            SLAB_HWCACHE_ALIGN, NULL);
>>>> +            SLAB_HWCACHE_ALIGN | SLAB_TYPESAFE_BY_RCU, NULL);
>>>>       if (!sched_fence_slab)
>>>>               return -ENOMEM;
>>>>
>>> Reviewed-by: Luben Tuikov <luben.tuikov at amd.com>
>>>
>>> But let it simmer for 24 hours so Christian can see it too (CC-ed).
>> Well that won't work like this, using the the SLAB_TYPESAFE_BY_RCU flag
>> was suggested before and is not allowed for dma_fence objects.
>>
>> The flag SLAB_TYPESAFE_BY_RCU can only be used if the objects in the
>> slab can't be reused within an RCU time period or if that reuse doesn't
>> matter for the logic. And exactly that is not guaranteed for dma_fence
>> objects.
> I think that is only true because of the drm_sched_fence_free() path?
> But that could also use call_rcu().  (It looks like it is only an
> error path.)

No, that's completely unrelated to that.

The SLAB_TYPESAFE_BY_RCU flag works only if you don't use 
kref_get_unless_zero() on the object.

The problem is basically that objects allocated with that flag can be 
re-used under RCU, but only for the same type of object.

This is ok as long as you only need information from the object to 
decide something and can still double check if you got the right object 
through different means.

But when the object can be re-used while in the critical section you can 
end up for example grabbing a reference to something completely 
unrelated to your code path.

The Intel guys had some very bad surprises with that and dma_fence as 
well as other objects.

>> It should also not be necessary because the scheduler fences are
>> released using call_rcu:
>>
>> static void drm_sched_fence_release_scheduled(struct dma_fence *f)
>> {
>>           struct drm_sched_fence *fence = to_drm_sched_fence(f);
>>
>>           dma_fence_put(fence->parent);
>>           call_rcu(&fence->finished.rcu, drm_sched_fence_free_rcu);
>> }
>>
>> That looks more like you have a reference count problem in MSM.
> Possibly I need to use rcu_read_lock()?  But I think the idr_lock
> which protected dma_fence_get_rcu() (and is held until the fence is
> removed from fence_idr, before it's reference is dropped in
> __msm_gem_submit_destroy()) makes that unnecessary.

Well you can either use a RCU protected pointer with dma_fence_get_rcu() 
inside a rcu_read_lock()/unlock() cirtical section.

Or you have some protection in the form of a lock, but then you should 
use dma_fence_get() instead.

Mixing those two doesn't make much sense.

Regards,
Christian.

>
> BR,
> -R
>
>> Regards,
>> Christian.