Re: [PATCH V18 03/14] drm/xe: Extend BO purge to handle vram pages as well

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Calling `xe_bo_is_vram()` on a purged BO causes a NULL pointer dereference because `bo->ttm.resource` is NULL.
--

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

drm/xe: Extend BO purge to handle vram pages as well

Recent driver update introduce support for purgeable buffer
objects (BOs), extending the API to include VRAM pages to
better manage memory pressure and enable memory offlining.

> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index dde309821237b..52f81e972adad 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -921,7 +921,7 @@ void xe_bo_set_purgeable_state(struct xe_bo *bo,
>   *
>   * Return: 0 on success, negative error code on failure
>   */
> -static int xe_ttm_bo_purge(struct ttm_buffer_object *ttm_bo, struct ttm_operation_ctx *ctx)
> +int xe_ttm_bo_purge(struct ttm_buffer_object *ttm_bo, struct ttm_operation_ctx *ctx)
>  {
>  	struct xe_bo *bo = ttm_to_xe_bo(ttm_bo);
>  	struct ttm_placement place = {};
> @@ -929,9 +929,6 @@ static int xe_ttm_bo_purge(struct ttm_buffer_object *ttm_bo, struct ttm_operatio
>  
>  	xe_bo_assert_held(bo);
>  
> -	if (!ttm_bo->ttm)
> -		return 0;
> -

[Severity: Critical]
This is a pre-existing issue, but I have a question about how xe_bo_is_vram()
handles purged BOs.

When a BO is purged, its TTM resource is freed and set to NULL. However,
xe_bo_is_vram() unconditionally passes bo->ttm.resource to resource_is_vram(),
which then dereferences it:

drivers/gpu/drm/xe/xe_bo.c:xe_bo_is_vram() {
	return resource_is_vram(bo->ttm.resource) ||
		resource_is_stolen_vram(xe_bo_device(bo), bo->ttm.resource);
}

drivers/gpu/drm/xe/xe_bo.c:resource_is_vram() {
	return mem_type_is_vram(res->mem_type);
}

This can lead to a NULL pointer dereference. For instance, in madvise_atomic(),
an unprivileged user can trigger this on a purged BO:

drivers/gpu/drm/xe/xe_vm_madvise.c:madvise_atomic() {
    ...
		/* Invalidate cpu page table, so bo can migrate to smem in next access */
		if (xe_bo_is_vram(bo) &&
		    (bo->attr.atomic_access == DRM_XE_ATOMIC_CPU ||
		     bo->attr.atomic_access == DRM_XE_ATOMIC_GLOBAL))
			ttm_bo_unmap_virtual(&bo->ttm);
    ...
}

It is also called unguarded in xe_pt_target_leaf_level_from_bo(), which could
crash during VM rebind if debug page size mode is enabled:

drivers/gpu/drm/xe/xe_pt.c:xe_pt_target_leaf_level_from_bo() {
    ...
	if (!bo || !xe_bo_is_vram(bo) || !(bo->flags & XE_BO_FLAG_USER))
		return 0;
    ...
}

Does xe_bo_is_vram() need a check for !bo->ttm.resource before accessing
res->mem_type to prevent a kernel oops or panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826135136.204044-16-tejas.upadhyay@intel.com?part=3