nreserve BO on errors in qxl_bo_pin_and_vmap() (Dmitry)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: b33651a5c98d ("drm/qxl: Do not pin buffer objects for vmap")
> Reported-by: David Kaplan
> Closes:
> https://lore.kernel.org/dri-devel/ab0fb17d-0f96-4ee6-8b21-65d02bb02...
On 7/2/24 17:20, Thomas Zimmermann wrote:
> @@ -190,7 +190,13 @@ int qxl_bo_vmap(struct qxl_bo *bo, struct iosys_map *map)
> if (r)
> return r;
>
> + r = qxl_bo_pin_locked(bo);
> + if (r)
> + return r;
Is qxl_bo_unreserve() missing here?
> +
> r = q
callbacks
> drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()
> drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
> drm/client: Pin vmap'ed GEM buffers
> drm/gem-vram: Do not pin buffer objects for vmap
> drm/qxl: Do not pin buffer objects for vmap
The patches look good. I gave them fbtest on virtio-gpu, no problems
spotted.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko # virtio-gpu
--
Best regards,
Dmitry
On 2/28/24 11:19, Thomas Zimmermann wrote:
> Hi
>
> Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
>> Hello,
>>
>> Thank you for the patches!
>>
>> On 2/27/24 13:14, Thomas Zimmermann wrote:
>>> Dma-buf locking semantics require the caller of pin and
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
> for
On 10/20/22 06:38, Dmitry Osipenko wrote:
> On 10/20/22 06:23, kernel test robot wrote:
>> Greeting,
>>
>> FYI, we noticed WARNING:at_drivers/gpu/drm/drm_gem.c:#drm_gem_vunmap due to
>> commit (built with clang-14):
>>
>> commit: 79e2cf2e7a193473d
On 10/20/22 06:23, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed WARNING:at_drivers/gpu/drm/drm_gem.c:#drm_gem_vunmap due to
> commit (built with clang-14):
>
> commit: 79e2cf2e7a193473dfb0da3b9b869682b43dc60f ("drm/gem: Take reservation
> lock for vmap/vunmap operations")
> git://an
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.
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
>>
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
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
.
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
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
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
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
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/
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
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
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
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
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
---
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
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/
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-
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
.
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
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
27 matches
Mail list logo
