public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: "Lin, Shuicheng" <shuicheng.lin@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 3/4] drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure
Date: Wed, 8 Apr 2026 09:41:13 -0700	[thread overview]
Message-ID: <adaFKRnqeKcLqYmw@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <DM4PR11MB545631685E1E7994F737E904EA5B2@DM4PR11MB5456.namprd11.prod.outlook.com>

On Wed, Apr 08, 2026 at 09:58:06AM -0600, Lin, Shuicheng wrote:
> On Tue, Apr 7, 2026 10:01 PM Matthew Brost wrote:
> > On Tue, Apr 07, 2026 at 08:15:41PM +0000, Shuicheng Lin wrote:
> > > When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo
> > > is not freed. Add xe_bo_free(storage) before returning the error.
> > >
> > > Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive
> > > eviction")
> > > Cc: stable@vger.kernel.org
> > > Assisted-by: Claude:claude-opus-4.6
> > > Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_dma_buf.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c
> > > b/drivers/gpu/drm/xe/xe_dma_buf.c index 7f9602b3363d..24d9d82426b9
> > > 100644
> > > --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> > > +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> > > @@ -271,8 +271,10 @@ xe_dma_buf_init_obj(struct drm_device *dev, struct
> > xe_bo *storage,
> > >  	int ret = 0;
> > >
> > >  	dummy_obj = drm_gpuvm_resv_object_alloc(&xe->drm);
> > > -	if (!dummy_obj)
> > > +	if (!dummy_obj) {
> > 
> > I know the comment at caller says 'Errors here will take care of freeing the bo.'
> > 
> > But I'm not sure that is right sematic as this patch alone won't free the BO give
> > this line not seen in this diff:
> > 
> > 296         return ret ? ERR_PTR(ret) : &bo->ttm.base;
> > 
> > So IMO we make the caller own the freeing of the BO here.
> 
> xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the BO on error.
> Therefore, xe_dma_buf_init_obj() must also free the BO on its error paths.

Yes, right. It is easy to forget these consuming interfaces on error.

> Otherwise, since xe_gem_prime_import() cannot distinguish whether the failure originated from xe_dma_buf_init_obj() or from xe_bo_init_locked(), it cannot safely decide whether the BO should be freed.
> 
> On success, ownership of the BO is transferred to the drm_gem_object.
> 
> How about add some comments in this function like below?
> 
> +/*
> + * Takes ownership of @storage: on success it is transferred to the returned
> + * drm_gem_object; on failure it is freed before returning the error.
> + * This matches the contract of xe_bo_init_locked() which frees @storage on
> + * its error paths, so callers need not (and must not) free @storage after
> + * this call.
> + */

Yes, that's good to avoid forgetting.

So this patch looks correct:

Reviewed-by: Matthew Brost <matthew.brost@intel.com>

>  static struct drm_gem_object *
>  xe_dma_buf_init_obj(struct drm_device *dev, struct xe_bo *storage,
>                     struct dma_buf *dma_buf)
> 
> Shuicheng
> 
> > 
> > Matt
> > 
> > > +		xe_bo_free(storage);
> > >  		return ERR_PTR(-ENOMEM);
> > > +	}
> > >
> > >  	dummy_obj->resv = resv;
> > >  	xe_validation_guard(&ctx, &xe->val, &exec, (struct xe_val_flags) {},
> > > ret) {
> > > --
> > > 2.43.0
> > >

  reply	other threads:[~2026-04-08 16:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260407201542.3396317-1-shuicheng.lin@intel.com>
2026-04-07 20:15 ` [PATCH 1/4] drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked() Shuicheng Lin
2026-04-08  4:52   ` Matthew Brost
2026-04-07 20:15 ` [PATCH 2/4] drm/xe/bo: Fix bo leak on GGTT flag " Shuicheng Lin
2026-04-08  4:54   ` Matthew Brost
2026-04-07 20:15 ` [PATCH 3/4] drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure Shuicheng Lin
2026-04-08  5:01   ` Matthew Brost
2026-04-08 15:58     ` Lin, Shuicheng
2026-04-08 16:41       ` Matthew Brost [this message]
2026-04-07 20:15 ` [PATCH 4/4] drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() Shuicheng Lin
2026-04-08  5:04   ` Matthew Brost
2026-04-08 17:34     ` Lin, Shuicheng
2026-04-08 17:38       ` Matthew Brost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adaFKRnqeKcLqYmw@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=shuicheng.lin@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox