Re: [PATCH v5 07/10] 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:
- [High] The fallback condition for `vm` in `msm_gpu_create_private_vm` incorrectly uses `!kernel_managed` instead of `kernel_managed`, breaking legacy contexts on older hardware and failing to prevent fallback for VM_BIND contexts.
--

--- Patch [7]: [PATCH v5 07/10] drm/msm: Don't fallback to shared VM for VM_BIND ---
commit fff36b547a5d97354f5a0baebf86eafdd34bd4f8
Author: Rob Clark <robin.clark@oss.qualcomm.com>
Date:   Thu Jul 16 20:15:30 2026 +0000

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

This commit modifies the fallback logic for VM creation to prevent userspace 
managed VMs (VM_BIND) from falling back to the shared kernel-managed VM if 
private VM creation fails.

[ ... ]

> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 18ed00e5f143b..d02c37380414b 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -875,7 +875,7 @@ msm_gpu_create_private_vm(struct msm_gpu *gpu, struct task_struct *task,
>  			to_msm_vm(vm)->pid = get_pid(task_pid(task));
>  	}
>  
> -	if (IS_ERR_OR_NULL(vm))
> +	if (IS_ERR_OR_NULL(vm) && !kernel_managed)

[Severity: High]
Does this boolean logic operate backwards from the stated intent of the patch?

If a legacy application runs on older hardware (A5xx or prior) that lacks
private VM support, kernel_managed is true. The !kernel_managed check
evaluates to false, skipping the fallback and returning NULL or an error.
Would this break command submission on these platforms?

Conversely, if a VM_BIND context (kernel_managed == false) fails to create
a private VM due to memory pressure, the !kernel_managed check evaluates to
true. This causes it to fall back to the kernel-managed shared VM, allowing
the very behavior the patch was trying to prevent.

If that VM_BIND fallback occurs, could it trigger a kernel panic later?
Userspace could issue a VM_BIND ioctl with a non-zero offset against the
erroneously assigned kernel-managed VM, hitting this BUG_ON:

drivers/gpu/drm/msm/msm_gem_vma.c:msm_gem_vma_new() {
    ...
    if (vm->managed) {
        BUG_ON(offset != 0);
        BUG_ON(!obj);
    ...
}

>  		vm = drm_gpuvm_get(gpu->vm);
>  
>  	return vm;

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