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

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 23 Jun 2026 22:44:21 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> On Tue, 23 Jun 2026 22:03:41 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
> 
> > Anyway, I'll try to get back to this map_pages() implementation, and
> > see how we can handle the fallback when locks can't be acquired in that
> > path (I assume this would mean no PMD mapping in the fallback path if
> > we get rid of huge_fault()).  
> 
> More on that. I had a brief look at map_pages()/fault_around(), and it
> seems it's only meant to populate PTE entries, not PMDs.

I was wrong, filemap_map_pages() clearly attempts a huge_page map if
the conditions are met (proper alignment of VMA, folio is huge, ...).

Now, I have several questions around how to implement map_pages()
properly in our case.

Ideally we would use a generic helper like filemap_map_pages(), which
basically all implementer of .map_pages() are using, because the loop,
checks and locking is far from trivial there. Unfortunately we can't
really use that one because
   a. in our case, the vm_file attached to the vma is a pseudo file that
      doesn't really back the data. Things are redirected internally to
      another file object that's backed by shmem, meaning the
      vmf->vm_pgoff and vmf->vma info are unusable as-is
   b. we use PFN insertion instead of page insertion since [1]

I'm sure we can hand-roll our own map_pages() implementation, but
again, we would need custom versions of the vmf_insert_pfn() to have an
optimal version that can batch multiple PTE updates (just like
filemap_map_folio_range() does). The pte/pmd locking also looks a bit
different too in map_pages(). These are all rather tricky details that
are hard to sort out when you don't know MM internals and the various
pitfalls around page table updates. Long story short, if you really want
us to move away from .huge_fault(), we're gonna need a bit of
hand-holding, because otherwise we're shooting in the dark.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v7.1&id=8b93d1d7dbd578fd296e70008b29c0f62d09d7cb