Re: [PATCH v6 14/16] drm/msm: Don't fallback to shared VM for VM_BIND

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch exposes a tight-loop, unbounded memory leak of MMU pagetables by failing to cache error states during lazy VM initialization.
--

--- Patch [14]: [PATCH v6 14/16] drm/msm: Don't fallback to shared VM for VM_BIND ---
commit 4383cea99723fe11a1653c676500fab3a15f1fda
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm: Don't fallback to shared VM for VM_BIND

If the user wants a userspace managed VM (EN_VM_BIND) don't silently
fall back to shared VM.

> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 3bd9a13837be3..50cc32184bb9d 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -235,7 +235,8 @@ struct drm_gpuvm *msm_context_vm(struct drm_device *dev, struct msm_context *ctx
>  	if (!ctx->vm) {
>  		vm = msm_gpu_create_private_vm(
>  			priv->gpu, current, !ctx->userspace_managed_vm);
> -		smp_store_release(&ctx->vm, vm);
> +		if (!IS_ERR_OR_NULL(vm))
> +			smp_store_release(&ctx->vm, vm);

[Severity: High]
This is a pre-existing issue, but does discarding the error pointer here
expose a tight loop memory leak of the mmu pagetables?

If msm_gpu_create_private_vm() returns an error pointer, ctx->vm stays NULL.
This allows userspace to repeatedly trigger vm creation on the same context
by calling the submit ioctl in a tight loop.

When msm_gpu_create_private_vm() fails (for example, if drm_sched_init()
fails inside msm_gem_vm_create()), the underlying mmu object allocated in
a6xx_create_private_vm() is leaked.

Previously, msm_gpu_create_private_vm() replaced this error pointer with a
fallback to gpu->vm. This bounded the leak to once per context. Because this
patch restricts the fallback to kernel managed vms, userspace managed vms
now return the error pointer directly.

Could we cache the error state in ctx->vm so we don't continually retry
failing vm creations, or fix the underlying leak by freeing the mmu object
on error?

>  	}
>  
>  	return ctx->vm;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717204841.26120-1-robin.clark@oss.qualcomm.com?part=14