Re: [PATCH] drm/xe/vm: Handle purged BOs in VM snapshots

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

On Thu, Sep 03, 2026 at 02:36:30PM +0530, Arvind Yadav wrote:
> A purged BO can remain in a VM after its TTM resource has been freed.
> xe_vm_snapshot_capture() can then dereference a NULL resource while
> capturing a devcoredump.
> 
> Record -ENODATA for the affected VMA instead of dereferencing
> the resource.
> 
> Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260831064942.315720-17-tejas.upadhyay%40intel.com?part=4
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_vm.c | 28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index 19b3d0be7928..77a851d9e373 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -4666,17 +4666,23 @@ struct xe_vm_snapshot *xe_vm_snapshot_capture(struct xe_vm *vm)
>  			snap->snap[i].cpu_caching = bo->cpu_caching;
>  			snap->snap[i].bo = xe_bo_get(bo);
>  			snap->snap[i].bo_ofs = xe_vma_bo_offset(vma);
> -			switch (bo->ttm.resource->mem_type) {
> -			case XE_PL_SYSTEM:
> -			case XE_PL_TT:
> -				snap->snap[i].uapi_mem_region = 0;
> -				break;
> -			case XE_PL_VRAM0:
> -				snap->snap[i].uapi_mem_region = 1;
> -				break;
> -			case XE_PL_VRAM1:
> -				snap->snap[i].uapi_mem_region = 2;
> -				break;
> +			snap->snap[i].uapi_mem_region = -1;
> +
> +			if (!bo->ttm.resource) {

I think technically this can change at any moment, so this is a TOCTOU
issue with the switch below.

The value is only stable while holding the dma-resv lock, which we can't
take here because we're in the signaling path.

To at least avoid a NULL pointer dereference, could we do something
like:

res = READ_ONCE(bo->ttm.resource);
 
if (!res)
	error;
else
	switch (res->mem_type)

KASAN could still complain if res is freed after the read, but the
kernel wouldn't explode, which is objectively better than both the
current situation and this patch.

Maybe someone has a better solution that fully closes this race? I'm
actually spotting a few other issues in xe_vm_snapshot_capture_delayed()
where eviction can race as well and those should be cleaned up too.

Perhaps we should open a broader Jira covering all devcoredump paths
that access BOs which may be moving, and clean up all of these issues in
a separate series.

Matt

> +				snap->snap[i].data = ERR_PTR(-ENODATA);
> +			} else {
> +				switch (bo->ttm.resource->mem_type) {
> +				case XE_PL_SYSTEM:
> +				case XE_PL_TT:
> +					snap->snap[i].uapi_mem_region = 0;
> +					break;
> +				case XE_PL_VRAM0:
> +					snap->snap[i].uapi_mem_region = 1;
> +					break;
> +				case XE_PL_VRAM1:
> +					snap->snap[i].uapi_mem_region = 2;
> +					break;
> +				}
>  			}
>  		} else if (xe_vma_is_userptr(vma)) {
>  			struct mm_struct *mm =
> -- 
> 2.43.0
>