linux-kernel - Re: [PATCH] drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACSVV02uJCRW8imFz7Q4fDZ3gfwkjQW2TkKYEVKLrfs4bXRFCg@mail.gmail.com>
Date: Mon, 25 Aug 2025 06:08:34 -0700
From: Rob Clark <rob.clark@....qualcomm.com>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Jessica Zhang <jessica.zhang@....qualcomm.com>,
        Sean Paul <sean@...rly.run>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Matthew Brost <matthew.brost@...el.com>,
        Himal Prasad Ghimiray <himal.prasad.ghimiray@...el.com>,
        Danilo Krummrich <dakr@...nel.org>, linux-arm-msm@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, Danct12 <danct12@...root.org>
Subject: Re: [PATCH] drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs

On Mon, Aug 25, 2025 at 12:09 AM Boris Brezillon
<boris.brezillon@...labora.com> wrote:
>
> On Sat, 23 Aug 2025 03:12:00 +0300
> Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> wrote:
>
> > Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM
> > driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not
> > allocate memptrs: -22" errors. The mentioned commit reworked the
> > function, but didn't take into account that op_map is initialized at the
> > top of the function, while ranges might change if GPUVM is managed by
> > the kernel.
> >
> > Move op_mode initialization after finalizing all addresses and right
> > before the drm_gpuva_init_from_op() call.
> >
> > Reported-by: Danct12 <danct12@...root.org>
> > Fixes: 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()")
> > Suggested-by: Rob Clark <robin.clark@....qualcomm.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
> > ---
> >  drivers/gpu/drm/msm/msm_gem_vma.c | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
> > index 3f440bc1f7106f3b0091f037611d0b433e5e2c18..6df6b7c0984da57fe64de41fa54f7dea0a324c74 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> > @@ -368,12 +368,6 @@ struct drm_gpuva *
> >  msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
> >               u64 offset, u64 range_start, u64 range_end)
> >  {
> > -     struct drm_gpuva_op_map op_map = {
> > -             .va.addr = range_start,
> > -             .va.range = range_end - range_start,
> > -             .gem.obj = obj,
> > -             .gem.offset = offset,
> > -     };
> >       struct msm_gem_vm *vm = to_msm_vm(gpuvm);
> >       struct drm_gpuvm_bo *vm_bo;
> >       struct msm_gem_vma *vma;
> > @@ -402,6 +396,13 @@ msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
> >       if (obj)
> >               GEM_WARN_ON((range_end - range_start) > obj->size);
> >
> > +     struct drm_gpuva_op_map op_map = {
> > +             .va.addr = range_start,
> > +             .va.range = range_end - range_start,
> > +             .gem.obj = obj,
> > +             .gem.offset = offset,
> > +     };
>
> OOC, are we now allowed to declare local variables in the middle of a
> code block in kernel code? I must admit that's not something I tried
> doing recently, but I've had gcc warnings in the past because of that.

yes.. I try not to go overboard with it, but this is a case where it
seems like the cleanest solution

BR,
-R

> > +
> >       drm_gpuva_init_from_op(&vma->base, &op_map);
> >       vma->mapped = false;
> >
> >
> > ---
> > base-commit: 0f4c93f7eb861acab537dbe94441817a270537bf
> > change-id: 20250823-msm-fix-gpuvm-init-520d87ebcf26
> >
> > Best regards,
>