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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Premature drop of VM reference in xe_bo_put_commit() allows the VM and its shared dma-resv to be freed while the BO is still alive in TTM, leading to a use-after-free on the resv.
--

commit b2fad1ac33df0229950ed8b4d71c885827c4b7e3
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Add XE_BO_FLAG_PUT_VM_ASYNC

This commit adds a new flag, XE_BO_FLAG_PUT_VM_ASYNC, which indicates that an
asynchronous BO put should also drop an additional reference to the BO's VM to
prevent the shared dma-resv from disappearing before the BO.

Link: https://patch.msgid.link/20260228013501.106680-7-matthew.brost@intel.com

> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index b162753cebb70..aea4b0fee8e33 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);

[Severity: High]
Does this sequence drop the VM reference prematurely and risk a use-after-free
on the VM's dma_resv?

Looking at xe_bo_put_commit(), we call drm_gem_object_free(), which can
trigger ttm_bo_release(). If ttm_bo_individualize_resv() fails due to
memory pressure while the VM's shared dma_resv is concurrently locked by
another thread, TTM handles this by queuing the BO for delayed deletion
via ttm_bo_delayed_delete() and returning early.

If TTM returns early keeping the BO alive, and we immediately proceed
to drop the VM reference here:

    drm_gem_object_free(&bo->ttm.base.refcount);
    if (async)
        xe_vm_put(vm);

could this free the VM and its embedded dma_resv if it was the last
reference? Later, when ttm_bo_delayed_delete() executes, it would
attempt to call dma_resv_lock(bo->base.resv) on the freed VM resv,
causing a regression.

Is there a mechanism to ensure the VM stays alive as long as TTM delays the
BO deletion?

> +	}
>  }

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904211613.3934307-1-matthew.brost@intel.com?part=6