[Intel-gfx] ✗ Fi.CI.IGT: failure for Move dma-buf mmap() reservation locking down to exporters (rev3)

== Series Details == Series: Move dma-buf mmap() reservation locking down to exporters (rev3) URL : https://patchwork.freedesktop.org/series/116000/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13169_full -> Patchwork_116000v3_full

[Intel-gfx] ✓ Fi.CI.BAT: success for Move dma-buf mmap() reservation locking down to exporters (rev3)

== Series Details == Series: Move dma-buf mmap() reservation locking down to exporters (rev3) URL : https://patchwork.freedesktop.org/series/116000/ State : success == Summary == CI Bug Log - changes from CI_DRM_13169 -> Patchwork_116000v3

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move dma-buf mmap() reservation locking down to exporters (rev3)

== Series Details == Series: Move dma-buf mmap() reservation locking down to exporters (rev3) URL : https://patchwork.freedesktop.org/series/116000/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v3 6/6] drm/shmem-helper: Switch to reservation lock

Replace all drm-shmem locks with a GEM reservation lock. This makes locks consistent with dma-buf locking convention where importers are responsible for holding reservation lock for all operations performed over dma-bufs, preventing deadlock between dma-buf importers and exporters. Suggested-by:

[Intel-gfx] [PATCH v3 5/6] dma-buf: Change locking policy for mmap()

Change locking policy of mmap() callback, making exporters responsible for handling dma-buf reservation locking. Previous locking policy stated that dma-buf is locked for both importers and exporters by the dma-buf core, which caused a deadlock problem for DRM drivers in a case of self-imported

[Intel-gfx] [PATCH v3 4/6] drm: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these

[Intel-gfx] [PATCH v3 2/6] dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these

[Intel-gfx] [PATCH v3 1/6] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these

[Intel-gfx] [PATCH v3 3/6] udmabuf: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these

[Intel-gfx] [PATCH v3 0/6] Move dma-buf mmap() reservation locking down to exporters

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