Re: [PATCH v7 14/17] drm/msm: Allow lazy VM creation to fail

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Bypass of per-process pgtable support check in adreno_set_param for MSM_PARAM_EN_VM_BIND
--

--- Patch [14]: [PATCH v7 14/17] drm/msm: Allow lazy VM creation to fail ---
commit 4152ad8d83f2b59969c7edf51ff58a105d0b46bf
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm: Allow lazy VM creation to fail

This commit updates the driver to handle failures during lazy VM creation,
returning ENOMEM or EPIPE instead of silently proceeding without a VM.
It modifies various entry points like gem_submit, vm_bind, and submitqueue
creation to validate the VM pointer.

> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 5738eac9aebd6..84101e534ebef 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -359,7 +359,7 @@ int adreno_fault_handler(struct msm_gpu *gpu, unsigned long iova, int flags,
>  static bool
>  valid_per_process_vm(struct msm_gpu *gpu, struct drm_gpuvm *vm)
>  {
> -	return (vm != gpu->vm);
> +	return vm && (vm != gpu->vm);
>  }
>  
>  int adreno_get_param(struct msm_gpu *gpu, struct msm_context *ctx,

[Severity: Critical]
This is a pre-existing issue, but while reviewing the VM validation changes
in this file, I noticed a potential check bypass in adreno_set_param().

If a platform lacks per-process pgtable support, lazy initialization means
ctx->vm will be NULL when adreno_set_param() is called.

Because ctx->vm is NULL, the following check:

    if (ctx->vm == gpu->vm)
            return UERR(EINVAL, drm, "requires per-process pgtables");

will evaluate to false. It will then pass the second check:

    if (ctx->vm)
            return UERR(EBUSY, drm, "VM already created");

and successfully set ctx->userspace_managed_vm to the requested value.

When the VM is later lazily created via msm_context_vm(), it falls back to
the global gpu->vm, improperly setting up the global VM as a VM_BIND queue.

Does this allow userspace to opt into VM_BIND functionality on a global,
kernel-managed GPU VM?

[ ... ]

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