Re: [PATCH 2/2] drm/msm: don't tear down shared VM mappings on handle close

[Alexey Minnekhanov]

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 <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
> ---
>   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 <alexeymin@xxxxxxxxxx>

--
Regards,
Alexey Minnekhanov