Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
in the affected places. Also revert any fixes on top. Separates references
to imported and exported DMA bufs within a GEM object; as before.
Using the dma_buf as the one authoritative field for the DMA buf turns
out to be fragile. The GEM object's dma_buf pointer can be NULL if
userspace releases the GEM handle too early. Sima mentioned that the fix
in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for
framebuffers") is conceptionally broken. Linus still notices boot-up
hangs that might be related.
Reverting the whole thing is the only sensible action here.
Tested on virtio; and amdgpu, simpledrm plus udl for dma-buf sharing.
Thomas Zimmermann (9):
Revert "drm/framebuffer: Acquire internal references on GEM handles"
Revert "drm/gem: Acquire references on GEM handles for framebuffers"
Revert "drm/virtio: Use dma_buf from GEM object instance"
Revert "drm/vmwgfx: Use dma_buf from GEM object instance"
Revert "drm/etnaviv: Use dma_buf from GEM object instance"
Revert "drm/prime: Use dma_buf from GEM object instance"
Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance"
Revert "drm/gem-shmem: Use dma_buf from GEM object instance"
Revert "drm/gem-dma: Use dma_buf from GEM object instance"
drivers/gpu/drm/drm_framebuffer.c | 31 +---------
drivers/gpu/drm/drm_gem.c | 64 +++-----------------
drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 8 ++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +-
drivers/gpu/drm/drm_internal.h | 2 -
drivers/gpu/drm/drm_prime.c | 8 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_prime.c | 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 +-
include/drm/drm_framebuffer.h | 7 ---
11 files changed, 35 insertions(+), 106 deletions(-)
--
2.50.0
