[PATCH 1/2] drm/ttm: fix locking in vmap/vunmap TTM GEM helpers

Christian König christian.koenig at amd.com
Tue Jul 19 07:27:14 UTC 2022


Am 19.07.22 um 09:19 schrieb Thomas Zimmermann:
> Hi
>
> Am 15.07.22 um 17:58 schrieb Christian König:
>> Am 15.07.22 um 17:36 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 15.07.22 um 13:15 schrieb Christian König:
>>>> I've stumbled over this while reviewing patches for DMA-buf and it 
>>>> looks
>>>> like we completely messed the locking up here.
>>>>
>>>> In general most TTM function should only be called while holding the
>>>> appropriate BO resv lock. Without this we could break the internal
>>>> buffer object state here.
>>>
>>> I remember that I tried to fix this before and you mentioned that 
>>> it's not allowed to hold this lock here. It would possibly deadlock 
>>> with exported buffers. Did this change with Dmitry's rework of the 
>>> locking semantics?
>>
>> No, can you point me to that?
>
> I thought it was somewhere in the lengthy discussion at
>
>
> https://lore.kernel.org/dri-devel/20201112132117.27228-1-tzimmermann@suse.de/ 
>
>
> but now I cannot find it any longer. :/
>
>>
>> My assumption was that drm_gem_vmap()/vunmap() is always called with 
>> the lock held, but Dmitry's work is now suggesting otherwise.
>
> IIRC the lock was supposed to be held, but every drivers does it 
> differently. And dma-buf locking essentially worked by chance.

I guess we where just lucky that nobody moved the BO while it was being 
mapped.

I've now pushed the patch to take the look to drm-misc-fixes. If some 
call path really called this while already holding the locks we will 
obviously run into trouble, but I think that should be pretty easy to 
sort out.

Regards,
Christian.

>
> Best regards
> Thomas
>
>>
>> We certainly need to hold the lock when we call 
>> ttm_bo_vmap()/vunmap() because it needs to access the bo->resource.
>>
>> Thanks,
>> Christian.
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>>>
>>>> Only compile tested!
>>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> Fixes: 43676605f890 drm/ttm: Add vmap/vunmap to TTM and TTM GEM 
>>>> helpers
>>>> ---
>>>>   drivers/gpu/drm/drm_gem_ttm_helper.c | 9 ++++++++-
>>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c 
>>>> b/drivers/gpu/drm/drm_gem_ttm_helper.c
>>>> index d5962a34c01d..e5fc875990c4 100644
>>>> --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
>>>> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
>>>> @@ -64,8 +64,13 @@ int drm_gem_ttm_vmap(struct drm_gem_object *gem,
>>>>                struct iosys_map *map)
>>>>   {
>>>>       struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
>>>> +    int ret;
>>>> +
>>>> +    dma_resv_lock(gem->resv, NULL);
>>>> +    ret = ttm_bo_vmap(bo, map);
>>>> +    dma_resv_unlock(gem->resv);
>>>>   -    return ttm_bo_vmap(bo, map);
>>>> +    return ret;
>>>>   }
>>>>   EXPORT_SYMBOL(drm_gem_ttm_vmap);
>>>>   @@ -82,7 +87,9 @@ void drm_gem_ttm_vunmap(struct drm_gem_object 
>>>> *gem,
>>>>   {
>>>>       struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
>>>>   +    dma_resv_lock(gem->resv, NULL);
>>>>       ttm_bo_vunmap(bo, map);
>>>> +    dma_resv_unlock(gem->resv);
>>>>   }
>>>>   EXPORT_SYMBOL(drm_gem_ttm_vunmap);
>>>
>>
>



More information about the dri-devel mailing list