On 22.08.2026 11:48, Dmitry Baryshkov wrote:
On targets (like A530 / MSM8996) without per-process pgtables
msm_gpu_create_private_vm() uses the global VM, so all DRM files share
one GPU address space. msm_gem_close() unmaps the object from ctx->vm,
which on those targets pulls the buffer out from under every other file
that still has it open, and frees the iova for immediate reuse.
A dma-buf imported into a second file hits this as soon as the exporter
closes its handle: the importer's texture keeps sampling the old
address, which the next allocation has taken over. On a530 this is
every ext_image_dma_buf_import sampling test, reading back all zeros.
The VMA teardown a shared VM needs is the one already used for kms->vm
-- defer it to the @vma_ref drop, when the last handle and dma_buf
reference are gone. That restores the pre-drm_gpuvm lifetime without
reintroducing the reference loop, since a BO with a live vma_ref is held
by userspace anyway.
Fixes: 111fdd2198e6 ("drm/msm: drm_gpuvm conversion")
Assisted-by: LLM
Signed-off-by: Dmitry Baryshkov <[email protected]>
---
drivers/gpu/drm/msm/msm_gem.c | 13 ++++++++++++-
drivers/gpu/drm/msm/msm_gpu.c | 4 +++-
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
Tested on device with a512, previously faults were easily reproducible,
like almost on every window/popup close.
They looked like
gpu fault: ttbr0=0000000046fdf000 iova=0000000004635f00 dir=READ
type=TRANSLATION source=1030001 (0,0,0,0)
gpu fault: ttbr0=0000000046fdf000 iova=000000000462d700 dir=READ
type=TRANSLATION source=2030001 (0,0,0,0)
gpu fault: ttbr0=0000000046fdf000 iova=0000000004c6e380 dir=READ
type=TRANSLATION source=4030001 (0,0,0,0)
gpu fault: ttbr0=0000000046fdf000 iova=000000000497eb00 dir=READ
type=TRANSLATION source=2030001 (0,0,0,0)
and now cannot be seen anymore with these series applied.
Tested-by: Alexey Minnekhanov <[email protected]>
--
Regards,
Alexey Minnekhanov
