Re: [PATCH v4 4/4] drm/xe: Bump prefetch BO LRU for already-valid ranges

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm_gpusvm: Type confusion on foreign coherent pages causes kernel panic
--

commit e6a84f5161e8175296073241c548503908bdb0fe
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>

drm/xe: Bump prefetch BO LRU for already-valid ranges

This commit adds xe_svm_range_prefetch_lru_bump() to refresh backing BOs on
the LRU for already-valid prefetch ranges. It avoids migration and binding
overhead by refaulting CPU pages without touching DMA mappings and moving
each backing BO to the LRU tail.

> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index d07dd95ab4514..909a602d091ea 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c

[ ... ]

> @@ -1659,6 +1659,40 @@ void xe_svm_devmem_lru_bump(struct drm_pagemap_devmem *devmem_allocation)
>  #endif
>  }
>  
> +/**
> + * xe_svm_range_prefetch_lru_bump() - Bump the TTM LRU for an already-valid range
> + * @vm: Pointer to the struct xe_vm
> + * @vma: Pointer to the VMA covering the range
> + * @range: Pointer to the xe SVM range structure
> + * @dpagemap: Target pagemap of the prefetch, or %NULL for system memory
> + *
> + * A valid range skips migration and binding, so nothing else refreshes its
> + * backing BOs on the LRU. Re-fault the CPU pages without touching the DMA
> + * mappings (@no_dma_map) and move each backing BO to the LRU tail.
> + *
> + * Prefetching is a best-effort optimization, so any failure is ignored; a
> + * later fault will refault the range.
> + */
> +void xe_svm_range_prefetch_lru_bump(struct xe_vm *vm, struct xe_vma *vma,
> +				    struct xe_svm_range *range,
> +				    struct drm_pagemap *dpagemap)
> +{
> +	struct drm_gpusvm_ctx ctx = {
> +		.read_only = xe_vma_read_only(vma),
> +		.device_private_page_owner =
> +			xe_svm_private_page_owner(vm, !dpagemap),
> +		.no_dma_map = 1,
> +		.devmem_fn = xe_svm_devmem_lru_bump,
> +	};
> +
> +	guard(mutex)(&range->lock);
> +
> +	if (xe_svm_range_is_removed(range))
> +		return;
> +
> +	xe_svm_range_get_pages(vm, range, &ctx);
> +}

[Severity: High]
Can this lead to a kernel panic due to a type confusion if a foreign driver's
MEMORY_DEVICE_COHERENT page is mapped?

If an unprivileged local user maps a foreign coherent page (for example, from
AMDGPU) into a VMA and triggers a prefetch here, xe_svm_range_get_pages()
eventually reaches drm_gpusvm_walk_devmem() in drivers/gpu/drm/drm_gpusvm.c.

Because HMM does not filter MEMORY_DEVICE_COHERENT pages by the
device_private_page_owner, drm_gpusvm_walk_devmem() proceeds:

drivers/gpu/drm/drm_gpusvm.c:drm_gpusvm_walk_devmem() {
    ...
    if (!is_device_private_page(page) &&
        !is_device_coherent_page(page)) {
        last = NULL;
        continue;
    }

    devmem = drm_pagemap_page_to_devmem(page);
    ...
}

This calls drm_pagemap_page_to_devmem() in drivers/gpu/drm/drm_pagemap.c,
which blindly casts the foreign driver's zone_device_data to a struct
drm_pagemap_zdd and reads devmem_allocation, yielding a garbage pointer.

The garbage pointer is then passed to the devmem_fn callback set in this
commit:

drivers/gpu/drm/xe/xe_svm.c:xe_svm_devmem_lru_bump() {
    ...
    if (devmem_allocation->ops != &dpagemap_devmem_ops)
        return;
    ...
}

This dereferences the garbage devmem_allocation pointer to check ops, causing
an immediate unhandled page fault and kernel panic before the validation check
can fail.

Is there a way to safely validate that the page is owned by drm_pagemap before
extracting and dereferencing the devmem_allocation pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001033602.3166274-6-himal.prasad.ghimiray@intel.com?part=4