[Intel-gfx] [PATCH v4 03/21] drm/gem: Take reservation lock for vmap/vunmap operations

patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c| 24 drivers/gpu/drm

[Intel-gfx] [PATCH v4 19/21] dma-buf: Document dynamic locking convention

Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 64

[Intel-gfx] [PATCH v4 04/21] drm/prime: Prepare to dynamic dma-buf locking specification

Prepare DRM prime core to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_prime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH v4 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification

Move dma-buf attachment mapping functions to the dynamic locking specification by asserting that the reservation lock is held. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b

[Intel-gfx] [PATCH v4 12/21] xen/gntdev: Prepare to dynamic dma-buf locking specification

Prepare gntdev driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/xen/gntdev-dmabuf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/xen/gntdev

Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

On 9/1/22 09:45, Christian König wrote: > Am 31.08.22 um 17:37 schrieb Dmitry Osipenko: >> Prepare i915 driver to the common dynamic dma-buf locking convention >> by starting to use the unlocked versions of dma-buf API functions >> and handling cases where importer now holds

[Intel-gfx] [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

[Intel-gfx] [PATCH v4 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification

Prepare OMAP DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a

[Intel-gfx] [PATCH v4 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification

Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/infiniband/core/umem_dmabuf.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a

[Intel-gfx] [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

ich was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (21): dma-buf: Add unlocked variant of vmapping functions dma-buf: Add unlocked variant of attachment-mapping functions drm/gem: Take reservation lock for

[Intel-gfx] [PATCH v4 16/21] dma-buf: Move dma_buf_attach() to dynamic locking specification

Move dma-buf attachment API functions to the dynamic locking specification by taking the reservation lock around the mapping operations. The strict locking convention prevents deadlock situations for dma-buf importers and exporters. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c

[Intel-gfx] [PATCH v4 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification

Move dma_buf_mmap() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --

Re: [Intel-gfx] [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

Hello Christian, On 9/1/22 10:49, Christian König wrote: > Hi Dmitry, > > I've gone over this multiple times now and while it is still possible > that we missed something I think that this should land now. Thank you very much for the review! > The whole topic is just to complicated that we can

[Intel-gfx] [PATCH v4 21/21] dma-buf: Remove obsoleted internal lock

d-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 14 -- include/linux/dma-buf.h | 9 - 2 files changed, 4 insertions(+), 19 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 97ce884fad76..772fdd9eeed8 100644 --- a/drivers/dma-bu

[Intel-gfx] [PATCH v4 20/21] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Acked-by: Hans Verkuil Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3

[Intel-gfx] [PATCH v4 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification

Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/dma

[Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

Prepare i915 driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions and handling cases where importer now holds the reservation lock. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2

[Intel-gfx] [PATCH v4 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification

Prepare V4L2 memory allocators to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++- drivers/media

[Intel-gfx] [PATCH v4 05/21] drm/armada: Prepare to dynamic dma-buf locking specification

Prepare Armada driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/armada/armada_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers

[Intel-gfx] [PATCH v4 01/21] dma-buf: Add unlocked variant of vmapping functions

Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized by drivers that don't take the reservation lock explicitly. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 38 ++ include/linux/dma-buf.h

Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

02.09.2022 13:31, Dmitry Osipenko пишет: > 01.09.2022 17:02, Ruhl, Michael J пишет: > ... >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(

Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

01.09.2022 17:02, Ruhl, Michael J пишет: ... >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >> drm_i915_private *i915, >> continue; >> } >> >

[Intel-gfx] [PATCH v3 1/9] dma-buf: Add _unlocked postfix to function names

nctions to take the reservation lock. Acked-by: Christian König Suggested-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 76 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

[Intel-gfx] [PATCH v3 7/9] dma-buf: Document dynamic locking convention

Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 63

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:24, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and expor

[Intel-gfx] [PATCH v3 3/9] drm/gem: Take reservation lock for vmap/vunmap operations

patch prepares DRM core and drivers for transitioning to the common dma-buf locking convention. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c| 24 drivers/gpu/drm

[Intel-gfx] [PATCH v3 8/9] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3 files changed, 3

Re: [Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:14, Christian König wrote: > Am 24.08.22 um 17:03 schrieb Dmitry Osipenko: >> On 8/24/22 17:08, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >>>> Move dma-buf attachment API functions to the dynamic locking >>>&

Re: [Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 17:08, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and expor

[Intel-gfx] [PATCH v3 4/9] dma-buf: Move dma_buf_vmap/vunmap_unlocked() to dynamic locking specification

Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by taking the reservation lock. All the affected drivers were prepared to this change by a previous drm/gem patch. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 8 drivers/gpu/drm

[Intel-gfx] [PATCH v3 0/9] Move all drivers to a common dma-buf locking convention

onvention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (9): dma-buf: Add _unlock

[Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

his patch makes them to take the lock. Intel and AMD GPU drivers already were mapping the attached dma-bufs under the held lock during attachment, hence these drivers are updated to use the locked functions. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c

[Intel-gfx] [PATCH v3 9/9] dma-buf: Remove internal lock

The internal dma-buf lock isn't needed anymore because the updated locking specification claims that dma-buf reservation must be locked by importers, and thus, the internal data is already protected by the reservation lock. Remove the obsoleted internal lock. Signed-off-by: Dmitry Osi

[Intel-gfx] [PATCH v3 5/9] dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification

Move dma_buf_mmap_unlocked() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf

[Intel-gfx] [PATCH v3 2/9] dma-buf: Add locked variant of dma_buf_vmap/vunmap()

Add locked variant of dma_buf_vmap/vunmap() that will be utilized by DRM drivers once vmap/unmap functions will be moved to the new locking convention. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 42 +++ include/linux/dma-buf.h | 2 ++ 2

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 20:45, Christian König wrote: > Am 24.08.22 um 17:49 schrieb Dmitry Osipenko: >> On 8/24/22 18:24, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >>>> Move dma-buf attachment API functions to the dynamic locking >>>&

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 14:30, Christian König wrote: >> + * - dma_buf_move_notify() > > This one is called by the exporter, not the importer. Good catch, thank you! -- Best regards, Dmitry

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 14:30, Christian König wrote: > Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: >> This patch moves the non-dynamic dma-buf users over to the dynamic >> locking specification. The strict locking convention prevents deadlock >> situation for dma-buf im

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/12/22 14:34, Christian König wrote: > > > Am 10.08.22 um 20:53 schrieb Dmitry Osipenko: >> On 8/10/22 21:25, Christian König wrote: >>> Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: >>>> On 8/10/22 14:30, Christian König wrote: >>>>> Am 25.

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 21:25, Christian König wrote: > Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: >> On 8/10/22 14:30, Christian König wrote: >>> Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: >>>> This patch moves the non-dynamic dma-buf users over to the dynamic >>

[Intel-gfx] [PATCH v2 1/5] dma-buf: Add _unlocked postfix to function names

nctions to take the reservation lock. Suggested-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 76 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +- drivers/gpu/

[Intel-gfx] [PATCH v2 0/5] Move all drivers to a common dma-buf locking convention

r should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he g

[Intel-gfx] [PATCH v2 4/5] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3 files changed, 3

[Intel-gfx] [PATCH v2 5/5] dma-buf: Remove internal lock

ff-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 5 - include/linux/dma-buf.h | 9 - 2 files changed, 14 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index bfdd551c7571..1d211ab400a1 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-bu

[Intel-gfx] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

n lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. Signed-off-by: Dmitry

[Intel-gfx] [PATCH v2 2/5] drm/gem: Take reservation lock for vmap/vunmap operations

lock. This patch prepares DRM core and drivers to transition to the common dma-buf locking convention where vmapping of exported GEMs will be done under the held reservation lock. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c

Re: [Intel-gfx] [PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

On 7/15/22 09:59, Dmitry Osipenko wrote: > On 7/15/22 09:50, Christian König wrote: >> Am 15.07.22 um 02:52 schrieb Dmitry Osipenko: >>> Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the >>> attachment to the i915 dma-buf. In order to let all

[Intel-gfx] [PATCH v1 0/6] Move all drivers to a common dma-buf locking convention

rest of the drivers share same or similar code paths. This is a continuation of [1] where Christian König asked to factor out the dma-buf locking changes into separate series. [1] https://lore.kernel.org/dri-devel/20220526235040.678984-1-dmitry.osipe...@collabora.com/ Dmitry Osipenko (6): dma-

Re: [Intel-gfx] [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj()

On 6/29/22 09:40, Thomas Hellström (Intel) wrote: > > On 5/27/22 01:50, Dmitry Osipenko wrote: >> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't >> handle imported dma-bufs properly, which results in mapping of something >> else than the impo

Re: [Intel-gfx] [PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

On 7/20/22 11:29, Christian König wrote: > Am 19.07.22 um 22:05 schrieb Dmitry Osipenko: >> On 7/15/22 09:59, Dmitry Osipenko wrote: >>> On 7/15/22 09:50, Christian König wrote: >>>> Am 15.07.22 um 02:52 schrieb Dmitry Osipenko: >>>>> Intel i915 GPU

Re: [Intel-gfx] [PATCH v6 14/22] dma-buf: Introduce new locking convention

On 7/1/22 13:43, Dmitry Osipenko wrote: > On 6/29/22 00:26, Thomas Hellström (Intel) wrote: >> On 5/30/22 15:57, Dmitry Osipenko wrote: >>> On 5/30/22 16:41, Christian König wrote: >>>> Hi Dmitry, >>>> >>>> Am 30.05.22 um 15:26 schrieb Dmitry O

Re: [Intel-gfx] [PATCH v6 01/22] drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error

On 6/28/22 23:12, Thomas Hellström (Intel) wrote: > Hi, > > On 5/27/22 01:50, Dmitry Osipenko wrote: >> Use ww_acquire_fini() in the error code paths. Otherwise lockdep >> thinks that lock is held when lock's memory is freed after the >> drm_gem_lock_reservat

Re: [Intel-gfx] [PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

On 7/15/22 09:50, Christian König wrote: > Am 15.07.22 um 02:52 schrieb Dmitry Osipenko: >> Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the >> attachment to the i915 dma-buf. In order to let all drivers utilize >> shared >> wait-wound context dur

[Intel-gfx] [PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

i915 driver to use the importer's ww context instead of the internal one. >From now on all dma-buf exporters shall use the importer's ww context for the attachment operation. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 8 +- drivers/gpu

Re: [Intel-gfx] [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

On 6/28/22 15:31, Robin Murphy wrote: > [  100.511411] > == > [  100.511419] BUG: KASAN: use-after-free in irq_work_single+0xa4/0x110 > [  100.511445] Write of size 4 at addr 107f5830 by task > glmark2-es2-drm/280 > [  100.5114

Re: [Intel-gfx] [Linaro-mm-sig] Re: [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj()

On 7/4/22 15:33, Christian König wrote: > Am 30.06.22 um 01:06 schrieb Dmitry Osipenko: >> On 6/29/22 11:43, Thomas Hellström (Intel) wrote: >>> On 6/29/22 10:22, Dmitry Osipenko wrote: >>>> On 6/29/22 09:40, Thomas Hellström (Intel) wrote: >>>>

Re: [Intel-gfx] [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj()

On 6/29/22 11:43, Thomas Hellström (Intel) wrote: > > On 6/29/22 10:22, Dmitry Osipenko wrote: >> On 6/29/22 09:40, Thomas Hellström (Intel) wrote: >>> On 5/27/22 01:50, Dmitry Osipenko wrote: >>>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers do

[Intel-gfx] [PATCH v1 5/6] media: videobuf2: Stop using internal dma-buf lock

. Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3 files changed, 3 insertions(+), 30 deletions

Re: [Intel-gfx] [PATCH v6 14/22] dma-buf: Introduce new locking convention

On 6/29/22 00:26, Thomas Hellström (Intel) wrote: > > On 5/30/22 15:57, Dmitry Osipenko wrote: >> On 5/30/22 16:41, Christian König wrote: >>> Hi Dmitry, >>> >>> Am 30.05.22 um 15:26 schrieb Dmitry Osipenko: >>>> Hello Christian, >>>>

[Intel-gfx] [PATCH v1 3/6] dma-buf: Move all dma-bufs to dynamic locking specification

r) to importers, otherwise lockdep won't be happy. This will be done in the next patch since i915 is the only driver that uses ww context on attachment today and it's not critical to make this change separately for i915 driver. Signed-off-by: Dmitry Osipenko ---

[Intel-gfx] [PATCH v1 1/6] dma-buf: Add _unlocked postfix to function names

nctions to take the reservation lock. Suggested-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 76 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +- drivers/gpu/

Re: [Intel-gfx] [PATCH v1 1/6] dma-buf: Add _unlocked postfix to function names

On 7/15/22 10:19, Christian König wrote: >> -struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment >> *attach, >> -    enum dma_data_direction direction) >> +struct sg_table * >> +dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach, >> +    enum

Re: [Intel-gfx] [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

On 6/28/22 15:31, Robin Murphy wrote: > ->8- > [   68.295951] == > [   68.295956] WARNING: possible circular locking dependency detected > [   68.295963] 5.19.0-rc3+ #400 Not tainted > [   68.295972] ---

Re: [Intel-gfx] [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

Hello Robin, On 6/28/22 15:31, Robin Murphy wrote: >> Hello, >> >> This patchset introduces memory shrinker for the VirtIO-GPU DRM driver >> and adds memory purging and eviction support to VirtIO-GPU driver. >> >> The new dma-buf locking convention is introduced here as well. >> >> During OOM, the

Re: [Intel-gfx] [PATCH v6 14/22] dma-buf: Introduce new locking convention

On 7/5/22 01:38, Dmitry Osipenko wrote: ... >>> Also i915 will run into trouble with attach. In particular since i915 >>> starts a full ww transaction in its attach callback to be able to lock >>> other objects if migration is needed. I think i915 CI would catch this >

[Intel-gfx] [PATCH v1 6/6] dma-buf: Remove internal lock

The internal dma-buf lock isn't needed anymore because the updated locking specification claims that dma-buf reservation must be locked by importers, and thus, the internal data is already protected by the reservation lock. Remove the obsoleted internal lock. Signed-off-by: Dmitry Osi

Re: [Intel-gfx] [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

On 6/28/22 19:48, Rob Clark wrote: > On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko > wrote: >> >> On 6/28/22 15:31, Robin Murphy wrote: >>> ->8- >>> [ 68.295951] == >>> [ 68.29595

[Intel-gfx] [PATCH v1 2/6] drm/gem: Take reservation lock for vmap/vunmap operations

lock. This patch prepares DRM core and drivers to transition to the common dma-buf locking convention where vmapping of exported GEMs will be done under the held reservation lock. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 +-- drivers/gpu/drm/drm_gem.c

Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

20.06.2022 18:37, Rob Clark пишет: >> +static unsigned long >> +drm_gem_shmem_shrinker_scan_objects(struct shrinker *shrinker, >> + struct shrink_control *sc) >> +{ >> + unsigned long nr_to_scan = sc->nr_to_scan; >> + bool lock_contention = false; >> +

Re: [Intel-gfx] [PATCH] drm/atomic: Make async plane update checks actually work as intended.

On 25.09.2017 09:43, Maarten Lankhorst wrote: > Op 24-09-17 om 16:33 schreef Dmitry Osipenko: >> On 04.09.2017 13:48, Maarten Lankhorst wrote: >>> By always keeping track of the last commit in plane_state, we know >>> whether there is an active update on the plane or not

Re: [Intel-gfx] [PATCH v2 6/6] drm/atomic: Make async plane update checks work as intended, v2.

On 04.09.2017 13:48, Maarten Lankhorst wrote: > By always keeping track of the last commit in plane_state, we know > whether there is an active update on the plane or not. With that > information we can reject the fast update, and force the slowpath > to be used as was originally intended. > > We

<    1   2   3