Re: [PATCH] drm/panthor: Check VMA boundaries for PMD mappings

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] VMA page offset calculation ignores VMA splits, causing the wrong GEM pages to be mapped
--

commit 0ed0c5c04749e14eb0003e5dbc760b6b5b001ce2
Author: Christian A. Ehrhardt <lk@c--e.de>

drm/panthor: Check VMA boundaries for PMD mappings

In the ->huge_fault handler do not install a PMD huge page mapping if the
huge page exceeds the boundaries of the VMA.

Link: https://lore.kernel.org/lkml/20260622215718.1532689-1-lk@c--e.de/
Link: https://sashiko.dev/#/patchset/20260622215718.1532689-1-lk%40c--e.de

> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> index a1e2eb1ca7bbe..54535bae2b0cf 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -802,9 +802,13 @@ static vm_fault_t insert_page(struct vm_fault *vmf, unsigned int order, struct p
>  	} else if (order == PMD_ORDER) {
>  		unsigned long pfn = page_to_pfn(page);
>  		unsigned long paddr = pfn << PAGE_SHIFT;
> +		struct vm_area_struct *vma = vmf->vma;
> +		unsigned long start = ALIGN_DOWN(vmf->address, PMD_SIZE);
> +		unsigned long end = start + PMD_SIZE;
> +		bool in_range = vma->vm_start <= start && end <= vma->vm_end;
>  		bool aligned = (vmf->address & ~PMD_MASK) == (paddr & ~PMD_MASK);
>  
> -		if (aligned &&
> +		if (aligned && in_range &&
>  		    folio_test_pmd_mappable(page_folio(page))) {
>  			pfn &= PMD_MASK >> PAGE_SHIFT;
>  			return vmf_insert_pfn_pmd(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);

[Severity: High]
This isn't a bug introduced by this patch, but looking further down in
panthor_gem_any_fault():

drivers/gpu/drm/panthor/panthor_gem.c:panthor_gem_any_fault() {
    ...
	/* Offset to faulty address in the VMA. */
	page_offset = vmf->pgoff - vma->vm_pgoff;
    ...
}

Does this VMA page offset calculation ignore VMA splits?

If a userspace process maps a Panthor GEM object and then unmaps the first
page using munmap(), the core memory management subsystem splits the VMA and
increments vma->vm_pgoff by 1.

When a page fault subsequently occurs at the new VMA start address, both
vmf->pgoff and vma->vm_pgoff have advanced by 1, which means page_offset
incorrectly evaluates to 0 instead of 1.

Could this logic error cause the fault handler to map incorrect physical
pages (bo->backing.pages[0] instead of bo->backing.pages[1]) from the GEM
object into userspace memory?

The calculation should probably subtract the GEM object's base fake offset
using drm_vma_node_start(&bo->base.vma_node).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623181942.1536598-1-lk@c--e.de?part=1