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 <[email protected]> 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/[email protected]/ 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/[email protected]?part=1
