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@xxxxxxxxxxxxx> -- Best regards, Dmitry
