Hi,
ignoring my r-b on patch 1, I'd like to rethink the current patches in general.
I think drm_gem_shmem_pin() should become the locked version of _pin(), so that drm_gem_shmem_object_pin() can call it directly. The existing _pin_unlocked() would not be needed any longer. Same for the _unpin() functions. This change would also fix the consistency with the semantics of the shmem _vmap() functions, which never take reservation locks.
There are only two external callers of drm_gem_shmem_pin(): the test case and panthor. These assume that drm_gem_shmem_pin() acquires the reservation lock. The test case should likely call drm_gem_pin() instead. That would acquire the reservation lock and the test would validate that shmem's pin helper integrates well into the overall GEM framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. For now, it could receive a wrapper that takes the lock and that's it.
Best regards Thomas
Am 01.05.24 um 08:55 schrieb Adrián Larumbe:
This is v3 of https://lore.kernel.org/dri-devel/20240424090429.57de7d1c@collabora.com/
The goal of this patch series is fixing a deadlock upon locking the dma reservation of a DRM gem object when pinning it, at a prime import operation.
Changes from v2:
- Removed comment explaining reason why an already-locked
pin function replaced the locked variant inside Panfrost's object pin callback.
- Moved already-assigned attachment warning into generic
already-locked gem object pin function
Adrián Larumbe (2): drm/panfrost: Fix dma_resv deadlock at drm object pin time drm/gem-shmem: Add import attachment warning to locked pin function
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++ drivers/gpu/drm/lima/lima_gem.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-)
base-commit: 75b68f22e39aafb22f3d8e3071e1aba73560788c