[PATCH 2/2] drm/vmwgfx: Make sure unpinning handles reservations

[Zack Rusin]

On 4/9/21 3:38 AM, Thomas Hellström (Intel) wrote:
> Hi, Zack,
> 
> On 4/8/21 7:22 PM, Zack Rusin wrote:
>> Quite often it's a little hard to tell if reservations are already held
>> in code paths that unpin bo's. While our pinning/unpinning code should
>> be more explicit that requires a substential amount of work so instead
>> we can avoid the issues by making sure we try to reserve before 
>> unpinning.
>> Because we unpin those bo's only on destruction/error paths just that 
>> check
>> tells us if we're already reserved or not and allows to cleanly unpin.
>>
>> Reviewed-by: Martin Krastev <krastevm at vmware.com>
>> Reviewed-by: Roland Scheidegger <sroland at vmware.com>
>> Fixes: d1a73c641afd ("drm/vmwgfx: Make sure we unpin no longer needed 
>> buffers")
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Zack Rusin <zackr at vmware.com>
>> ---
>>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 17 ++++++++++++++++-
>>   drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |  8 ++++----
>>   2 files changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> index 8087a9013455..03bef9c17e56 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> @@ -1517,6 +1517,21 @@ static inline struct vmw_surface 
>> *vmw_surface_reference(struct vmw_surface *srf)
>>       return srf;
>>   }
>> +/*
>> + * vmw_bo_unpin_safe - currently pinning requires a reservation to be 
>> held
>> + * but sometimes it's hard to tell if we're in a callback whose parent
>> + * is already holding a reservation, to avoid deadloacks we have to try
>> + * to get a reservation explicitly to also try to avoid messing up the
>> + * internal ttm lru bo list
>> + */
>> +static inline void vmw_bo_unpin_safe(struct ttm_buffer_object *bo)
>> +{
>> +    bool locked = dma_resv_trylock(bo->base.resv);
> 
> Isn't there a chance another thread is holding the lock and releasing it 
> at this position?

Yes, it was definitely possible. In v2 I implemented it the way Daniel 
suggested, I think it's a decent compromise. Thanks for taking a look at 
this!

z