Re: [PATCH V19 06/15] drm/xe: Guard teardown paths against purged BOs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `xe_bo_unpin_external()` lacks the `xe_bo_is_purged()` check, leading to pin count underflow for DMA-buf exported BOs.
--

commit b0d5d3f21885703ffe281bfc361768a0213d2668
Author: Tejas Upadhyay <tejas.upadhyay@intel.com>

drm/xe: Guard teardown paths against purged BOs

This commit adds xe_bo_is_purged() guards in several teardown paths
to prevent unpinning or mapping a buffer object that was already purged
by VRAM page offlining.

> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index c255327669da5..b162753cebb70 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -3267,6 +3267,9 @@ void xe_bo_unpin(struct xe_bo *bo)
>  	struct ttm_place *place = &bo->placements[0];
>  	struct xe_device *xe = xe_bo_device(bo);
>  
> +	if (xe_bo_is_purged(bo))
> +		return;
> +

[Severity: High]
Does xe_bo_unpin_external() also need this xe_bo_is_purged() check?

If a user BO is exported via DMA-buf, the VRAM page offline mechanism
can queue it for offlining. If the DMA-buf importer pins the BO, the
pin count increments. When the VRAM offline worker processes the queue,
it forcefully unpins and purges the BO, leaving the pin count at 0.

When the importer later unpins the BO, it triggers xe_dma_buf_unpin()
which calls xe_bo_unpin_external():

static void xe_dma_buf_unpin(struct dma_buf_attachment *attach)
{
	struct drm_gem_object *obj = attach->dmabuf->priv;
	struct xe_bo *bo = gem_to_xe_bo(obj);

	xe_bo_unpin_external(bo);
}

Since xe_bo_unpin_external() lacks the xe_bo_is_purged() guard, it
will call ttm_bo_unpin() unconditionally. Could this cause a pin count
underflow on the TTM BO and make the BO permanently un-evictable?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831064942.315720-17-tejas.upadhyay@intel.com?part=6