| Message ID | 20230402164826.752842-1-dmitry.osipenko@collabora.com |
|---|---|
| Headers | show |
| Series | Move dma-buf mmap() reservation locking down to exporters | expand |
On 4/2/23 19:48, Dmitry Osipenko wrote: > This patchset makes dma-buf exporters responisble for taking care of > the reservation lock. I also included patch that moves drm-shmem to use > reservation lock, to let CI test the whole set. I'm going to take all > the patches via the drm-misc tree, please give an ack. > > Previous policy stated that dma-buf core takes the lock around mmap() > callback. Which meant that both importers and exporters shouldn't touch > the reservation lock in the mmap() code path. This worked well until > Intel-CI found a deadlock problem in a case of self-imported dma-buf [1]. > > The problem happens when userpace mmaps a self-imported dma-buf, i.e. > mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs > [2]. There is no way to differentiate a prime GEM from a normal GEM for > drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem > for drm-shmem mmap() code path once it's switched to use reservation lock. > > It was difficult to fix the drm-shmem problem without adjusting dma-buf > locking policy. In parctice not much changed from importers perspective > because previosly dma-buf was taking the lock in between of importers > and exporters. Now this lock is shifted down to exporters. > > [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@sync@rcs0.html > [2] https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924 > > Dmitry Osipenko (7): > Revert "media: videobuf2: Assert held reservation lock for dma-buf > mmapping" > Revert "dma-buf/heaps: Assert held reservation lock for dma-buf > mmapping" > Revert "udmabuf: Assert held reservation lock for dma-buf mmapping" > Revert "fastrpc: Assert held reservation lock for dma-buf mmapping" > Revert "drm: Assert held reservation lock for dma-buf mmapping" > dma-buf: Change locking policy for mmap() > drm/shmem-helper: Switch to reservation lock > > drivers/dma-buf/dma-buf.c | 17 +- > drivers/dma-buf/heaps/cma_heap.c | 3 - > drivers/dma-buf/heaps/system_heap.c | 3 - > drivers/dma-buf/udmabuf.c | 2 - > drivers/gpu/drm/drm_gem_shmem_helper.c | 217 ++++++++---------- > drivers/gpu/drm/drm_prime.c | 2 - > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 - > drivers/gpu/drm/lima/lima_gem.c | 8 +- > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 - > drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +- > .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +- > drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +- > drivers/gpu/drm/tegra/gem.c | 2 - > .../common/videobuf2/videobuf2-dma-contig.c | 3 - > .../media/common/videobuf2/videobuf2-dma-sg.c | 3 - > .../common/videobuf2/videobuf2-vmalloc.c | 3 - > drivers/misc/fastrpc.c | 3 - > include/drm/drm_gem_shmem_helper.h | 14 +- > 18 files changed, 123 insertions(+), 193 deletions(-) > Intel's IGT passed[1] (see Tests section) with the new locking policy, which failed previously for the "drm/shmem-helper: Switch to reservation lock" patch. [1] https://patchwork.freedesktop.org/series/116000/
Hi Dmitry, On Sun, 2 Apr 2023 at 17:49, Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote: > -void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem) > +static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem) > { > - mutex_lock(&shmem->pages_lock); > - drm_gem_shmem_put_pages_locked(shmem); > - mutex_unlock(&shmem->pages_lock); > + struct drm_gem_object *obj = &shmem->base; > + int ret; > + > + dma_resv_assert_held(shmem->base.resv); > + > + drm_WARN_ON(obj->dev, obj->import_attach); > + We don't need this WARN_ON to happen with a reservation lock, do we? If so, let's leave that in the caller. > + ret = drm_gem_shmem_get_pages(shmem); > + > + return ret; > +} > + > +static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem) > +{ > + struct drm_gem_object *obj = &shmem->base; > + > + dma_resv_assert_held(shmem->base.resv); > + > + drm_WARN_ON(obj->dev, obj->import_attach); > + Ditto. With that the series is: Reviewed-by; Emil Velikov <emil.l.velikov@gmail.com> HTH -Emil
This patchset makes dma-buf exporters responisble for taking care of the reservation lock. I also included patch that moves drm-shmem to use reservation lock, to let CI test the whole set. I'm going to take all the patches via the drm-misc tree, please give an ack. Previous policy stated that dma-buf core takes the lock around mmap() callback. Which meant that both importers and exporters shouldn't touch the reservation lock in the mmap() code path. This worked well until Intel-CI found a deadlock problem in a case of self-imported dma-buf [1]. The problem happens when userpace mmaps a self-imported dma-buf, i.e. mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs [2]. There is no way to differentiate a prime GEM from a normal GEM for drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem for drm-shmem mmap() code path once it's switched to use reservation lock. It was difficult to fix the drm-shmem problem without adjusting dma-buf locking policy. In parctice not much changed from importers perspective because previosly dma-buf was taking the lock in between of importers and exporters. Now this lock is shifted down to exporters. [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@sync@rcs0.html [2] https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924 Dmitry Osipenko (7): Revert "media: videobuf2: Assert held reservation lock for dma-buf mmapping" Revert "dma-buf/heaps: Assert held reservation lock for dma-buf mmapping" Revert "udmabuf: Assert held reservation lock for dma-buf mmapping" Revert "fastrpc: Assert held reservation lock for dma-buf mmapping" Revert "drm: Assert held reservation lock for dma-buf mmapping" dma-buf: Change locking policy for mmap() drm/shmem-helper: Switch to reservation lock drivers/dma-buf/dma-buf.c | 17 +- drivers/dma-buf/heaps/cma_heap.c | 3 - drivers/dma-buf/heaps/system_heap.c | 3 - drivers/dma-buf/udmabuf.c | 2 - drivers/gpu/drm/drm_gem_shmem_helper.c | 217 ++++++++---------- drivers/gpu/drm/drm_prime.c | 2 - drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 - drivers/gpu/drm/lima/lima_gem.c | 8 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 - drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +- .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +- drivers/gpu/drm/tegra/gem.c | 2 - .../common/videobuf2/videobuf2-dma-contig.c | 3 - .../media/common/videobuf2/videobuf2-dma-sg.c | 3 - .../common/videobuf2/videobuf2-vmalloc.c | 3 - drivers/misc/fastrpc.c | 3 - include/drm/drm_gem_shmem_helper.h | 14 +- 18 files changed, 123 insertions(+), 193 deletions(-)