Re: [PATCH V21 04/15] drm/xe: Handle NULL resource and allow purging of VRAM pages

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing NULL check for bo->ttm.resource in xe_vm_snapshot_capture(), which will cause a kernel panic when devcoredump attempts to snapshot a purged BO.
- [High] xe_bo_migrate() and xe_bo_is_mem_type() unconditionally dereference bo->ttm.resource without checking for NULL, leading to a crash when called on purged BOs.
--

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

drm/xe: Handle NULL resource and allow purging of VRAM pages

Add NULL checks for the buffer object's resource pointer in
xe_bo_is_vram() and xe_bo_is_stolen() to prevent potential NULL
pointer dereferences when checking memory location during page
offlining.

Additionally, remove the `!ttm_bo->ttm` check from
xe_ttm_bo_purge(). This restriction is stripped away to
explicitly allow the driver to purge VRAM pages during the
memory page offline sequence.

> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 8f93e09e51bb8..d30a8411d2a33 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c

[ ... ]

> @@ -929,9 +932,6 @@ int xe_ttm_bo_purge(struct ttm_buffer_object *ttm_bo, struct ttm_operation_ctx *
>  
>  	xe_bo_assert_held(bo);
>  
> -	if (!ttm_bo->ttm)
> -		return 0;
> -

[Severity: High]
This isn't a bug introduced by this patch, but removing this restriction allows
VRAM BOs to be purged, which exposes a missing NULL check in
xe_vm_snapshot_capture().

If a userspace application maps a BO in a VM, marks its VMA as DONTNEED, and
memory pressure purges the BO, bo->ttm.resource becomes NULL.

If a GPU hang then occurs, devcoredump is triggered and xe_vm_snapshot_capture()
iterates over the VM's vma_list, unconditionally accessing
bo->ttm.resource->mem_type:

drivers/gpu/drm/xe/xe_vm.c:xe_vm_snapshot_capture() {
	...
	drm_gpuvm_for_each_va(gpuva, &vm->gpuvm) {
		...
		if (bo) {
			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:
			...
}

Will this cause a kernel panic when devcoredump attempts to snapshot a purged
BO?


[Severity: High]
This is another pre-existing issue, but expanding purgeability to VRAM BOs
makes it reachable for them as well.

If a BO is marked DONTNEED and purged via memory pressure
(bo->ttm.resource = NULL), and then utilized in a path that triggers migration
(such as pinning it to a KMS plane or exporting/pinning it via dma-buf), both
xe_bo_migrate() and xe_bo_is_mem_type() unconditionally dereference
bo->ttm.resource.

drivers/gpu/drm/xe/xe_bo.c:xe_bo_migrate() {
	...
	xe_bo_assert_held(bo);
	tctx = tctx ? tctx : &ctx;

	if (bo->ttm.resource->mem_type == mem_type)
		return 0;
	...
}

drivers/gpu/drm/xe/xe_bo.h:xe_bo_is_mem_type() {
	...
	xe_bo_assert_held(bo);
	return bo->ttm.resource->mem_type == mem_type;
}

Can this lead to a kernel panic when these functions are called on purged BOs?

>  	if (!xe_bo_madv_is_dontneed(bo))
>  		return 0;
>

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