On 5/11/22 17:24, Christian König wrote: > Am 11.05.22 um 15:00 schrieb Daniel Vetter: >> On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote: >>> [SNIP] >>> Since vmapping implies implicit pinning, we can't use a separate lock in >>> drm_gem_shmem_vmap() because we need to protect the >>> drm_gem_shmem_get_pages(), which is invoked by drm_gem_shmem_vmap() to >>> pin the pages and requires the dma_resv_lock to be locked. >>> >>> Hence the problem is: >>> >>> 1. If dma-buf importer holds the dma_resv_lock and invokes >>> dma_buf_vmap() -> drm_gem_shmem_vmap(), then drm_gem_shmem_vmap() shall >>> not take the dma_resv_lock. >>> >>> 2. Since dma-buf locking convention isn't specified, we can't assume >>> that dma-buf importer holds the dma_resv_lock around dma_buf_vmap(). >>> >>> The possible solutions are: >>> >>> 1. Specify the dma_resv_lock convention for dma-bufs and make all >>> drivers to follow it. >>> >>> 2. Make only DRM drivers to hold dma_resv_lock around dma_buf_vmap(). >>> Other non-DRM drivers will get the lockdep warning. >>> >>> 3. Make drm_gem_shmem_vmap() to take the dma_resv_lock and get deadlock >>> if dma-buf importer holds the lock. >>> >>> ... >> Yeah this is all very annoying. > > Ah, yes that topic again :) > > I think we could relatively easily fix that by just defining and > enforcing that the dma_resv_lock must have be taken by the caller when > dma_buf_vmap() is called. > > A two step approach should work: > 1. Move the call to dma_resv_lock() into the dma_buf_vmap() function and > remove all lock taking from the vmap callback implementations. > 2. Move the call to dma_resv_lock() into the callers of dma_buf_vmap() > and enforce that the function is called with the lock held. I've doubts about the need to move out the dma_resv_lock() into the callers of dma_buf_vmap().. I looked through all the dma_buf_vmap() users and neither of them interacts with dma_resv_lock() at all, i.e. nobody takes the lock in/outside of dma_buf_vmap(). Hence it's easy and more practical to make dma_buf_mmap/vmap() to take the dma_resv_lock by themselves. It's unclear to me which driver may ever want to do the mapping under the dma_resv_lock. But if we will ever have such a driver that will need to map imported buffer under dma_resv_lock, then we could always add the dma_buf_vmap_locked() variant of the function. In this case the locking rule will sound like this: "All dma-buf importers are responsible for holding the dma-reservation lock around the dmabuf->ops->mmap/vmap() calls." > It shouldn't be that hard to clean up. The last time I looked into it my > main problem was that we didn't had any easy unit test for it. Do we have any tests for dma-bufs at all? It's unclear to me what you are going to test in regards to the reservation locks, could you please clarify? -- Best regards, Dmitry
