linux-kernel - Re: [Intel-xe] [PATCH v2 2/4] drm/ttm: Don't shadow the operation context

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Jun 2023 17:23:27 +0200
From:   Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>
To:     Christian König 
        <ckoenig.leichtzumerken@...il.com>, intel-xe@...ts.freedesktop.org
Cc:     intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Roger He <Hongbo.He@....com>,
        dri-devel@...ts.freedesktop.org,
        Christian König <christian.koenig@....com>
Subject: Re: [Intel-xe] [PATCH v2 2/4] drm/ttm: Don't shadow the operation
 context

On Mon, 2023-06-26 at 17:18 +0200, Thomas Hellström wrote:
> On Mon, 2023-06-26 at 17:15 +0200, Christian König wrote:
> > Am 26.06.23 um 11:14 schrieb Thomas Hellström:
> > > ttm_bo_swapout() shadows the ttm operation context which may
> > > cause
> > > major confusion in driver callbacks when swapping out
> > > !TTM_PL_SYSTEM
> > > memory. Fix this by reusing the operation context argument to
> > > ttm_bo_swapout().
> > > 
> > > Cc: "Christian König" <christian.koenig@....com>
> > > Cc: Roger He <Hongbo.He@....com>
> > > Cc: <dri-devel@...ts.freedesktop.org>
> > > Cc: <intel-gfx@...ts.freedesktop.org>
> > > Cc: <stable@...r.kernel.org> # v4.16+
> > > Fixes: dc947770cf34 ("drm/ttm: enable swapout for reserved BOs
> > > during allocation")
> > > Signed-off-by: Thomas Hellström
> > > <thomas.hellstrom@...ux.intel.com>
> > > Acked-by: Matthew Brost <matthew.brost@...el.com>
> > 
> > We intentionally didn't used the parameter here, but I absolutely
> > can't 
> > figure out why.
> > 
> > Feel free to add my rb, but let's give it some time upstream before
> > you 
> > base anything on top of this. Just in case we missed something.
> 
> Sure. Thanks for reviewing,

BTW, I'll remove the Fixes: tag as well.

/Thomas


> /Thomas
> 
> > 
> > Regards,
> > Christian.
> > 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
> > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index bd5dae4d1624..615d30c4262d 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1154,7 +1154,6 @@ int ttm_bo_swapout(struct ttm_buffer_object
> > > *bo, struct ttm_operation_ctx *ctx,
> > >          * Move to system cached
> > >          */
> > >         if (bo->resource->mem_type != TTM_PL_SYSTEM) {
> > > -               struct ttm_operation_ctx ctx = { false, false };
> > >                 struct ttm_resource *evict_mem;
> > >                 struct ttm_place hop;
> > >   
> > > @@ -1164,7 +1163,7 @@ int ttm_bo_swapout(struct ttm_buffer_object
> > > *bo, struct ttm_operation_ctx *ctx,
> > >                 if (unlikely(ret))
> > >                         goto out;
> > >   
> > > -               ret = ttm_bo_handle_move_mem(bo, evict_mem, true,
> > > &ctx, &hop);
> > > +               ret = ttm_bo_handle_move_mem(bo, evict_mem, true,
> > > ctx, &hop);
> > >                 if (unlikely(ret != 0)) {
> > >                         WARN(ret == -EMULTIHOP, "Unexpected
> > > multihop in swaput - likely driver bug.\n");
> > >                         goto out;
> > 
>