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

[Dmitry Osipenko]

On 7/15/22 18:58, Christian König wrote:
> 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?
> 
> My assumption was that drm_gem_vmap()/vunmap() is always called with the
> lock held, but Dmitry's work is now suggesting otherwise.
> 
> We certainly need to hold the lock when we call ttm_bo_vmap()/vunmap()
> because it needs to access the bo->resource.

The today's vmapping code paths all should be unlocked for the exported
TTM dma-bufs. My locking patches will change that. To me the Christian's
fix looks good. If there are out-of-tree drivers that do the locking on
the importer side, then we don't really care about them in the upstream
and they will have to adapt.

Reviewed-by: Dmitry Osipenko <dmitry.osipenko at collabora.com>

-- 
Best regards,
Dmitry