Re: [PATCH v6 06/24] drm/xe: Add XE_BO_FLAG_PUT_VM_ASYNC

[Matthew Brost <matthew.brost@intel.com>]

On Fri, Sep 11, 2026 at 03:10:48PM +0200, Francois Dugast wrote:
> On Fri, Sep 04, 2026 at 02:15:55PM -0700, Matthew Brost wrote:
> > Add XE_BO_FLAG_PUT_VM_ASYNC, which indicates that an async BO put must
> > also drop an additional reference to the BO’s VM. This is useful when a
> > kernel BO, one that does not normally hold a VM reference, needs to be
> > put asynchronously, ensuring the shared dma-resv object does not
> > disappear before the BO.
> > 
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > Link: https://patch.msgid.link/20260228013501.106680-7-matthew.brost@intel.com
> > Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
> > ---
> >  drivers/gpu/drm/xe/xe_bo.c | 8 +++++++-
> >  drivers/gpu/drm/xe/xe_bo.h | 1 +
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> > index b162753cebb7..aea4b0fee8e3 100644
> > --- a/drivers/gpu/drm/xe/xe_bo.c
> > +++ b/drivers/gpu/drm/xe/xe_bo.c
> > @@ -3998,8 +3998,14 @@ void xe_bo_put_commit(struct llist_head *deferred)
> >  	if (!freed)
> >  		return;
> >  
> > -	llist_for_each_entry_safe(bo, next, freed, freed)
> > +	llist_for_each_entry_safe(bo, next, freed, freed) {
> > +		struct xe_vm *vm = bo->vm;
> > +		bool async = bo->flags & XE_BO_FLAG_PUT_VM_ASYNC;
> > +
> >  		drm_gem_object_free(&bo->ttm.base.refcount);
> > +		if (async)
> > +			xe_vm_put(vm);
> 
> You had mentioned reworking this part:
> https://patchwork.freedesktop.org/patch/750807/?series=149888&rev=6#comment_1383757
> 

I reworked the PT BO reference count reinitialization in the PT layer. The
Sashiko feedback was not correct in its original context, but it was
right that transitioning a BO reference count from zero to one on the
driver side is unsafe.

This change follows patch [1] in xe_pt_destroy. Compare it to the prior
revision [2]; note that the kref_init in [2] is gone in [1].

[1] https://patchwork.freedesktop.org/patch/751032/?series=149888&rev=8
[2] https://patchwork.freedesktop.org/patch/750792/?series=149888&rev=6

Wrt. the comment about ttm_bo_individualize_resv() failing, if that occurs
in ttm_bo_release() (we get here from drm_gem_object_free()), the fences
are waited on directly before returning. See the dma_resv_wait_timeout()
for 30 seconds, after which the BO is destroyed inline if VM lock can be
taken. I guess the VM lock can fall on a trylock, triggering the delayed
worker...

We could look at PT BOs holding a VM reference until xe_ttm_bo_destroy(),
similar to user BOs, but there is some convoluted reason why only user BOs
have held a VM reference from early on in Xe that may or may not still
be true. Let me see if I can make this work as after typing this out it
seems like an extreme corner case of posisble memory safety bug. 

Thanks,
Matt

> Sashiko seems consistent here.
> 
> Francois
> 
> > +	}
> >  }
> >  
> >  static void xe_bo_dev_work_func(struct work_struct *work)
> > diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h
> > index 01975586ee88..2168aac1ed1e 100644
> > --- a/drivers/gpu/drm/xe/xe_bo.h
> > +++ b/drivers/gpu/drm/xe/xe_bo.h
> > @@ -54,6 +54,7 @@
> >  #define XE_BO_FLAG_FORCE_USER_VRAM	BIT(25)
> >  #define XE_BO_FLAG_NO_COMPRESSION	BIT(26)
> >  #define XE_BO_FLAG_NEEDS_1G		BIT(27)
> > +#define XE_BO_FLAG_PUT_VM_ASYNC		BIT(28)
> >  
> >  /* this one is trigger internally only */
> >  #define XE_BO_FLAG_INTERNAL_TEST	BIT(30)
> > -- 
> > 2.34.1
> >