Re: [PATCH v3 0/6] mm: access remote process memory under the per-VMA lock

[Rik van Riel <riel@surriel.com>]

On Tue, 2026-07-21 at 20:12 +0200, David Hildenbrand (Arm) wrote:
> On 7/17/26 19:00, Rik van Riel wrote:
> 
> > 
> > get_user_pages_remote() does not fit: it hard codes the mmap lock
> > and
> > re-derives the VMA. get_user_page_vma() walks the page tables,
> > faults a
> > missing page in, and returns it with a reference and the caller's
> > lock
> > still held.
> 
> Agreed, and that can be tackled later.

I'll stop making this series (much) bigger, then ;)

I added a few things for v4, but I can save other
stuff for follow-ups.

> 
> > 
> > The per-VMA path also closes a pre-existing gap. A COWed page in a
> > VM_IO/VM_PFNMAP VMA has a struct page, but the old code routed it
> > to
> > ->access(), where generic_access_phys() ioremaps the PFN and
> > ioremap of RAM
> > is rejected, so the read came up short.
> 
> Yep. The GUP code rejected VM_IO/VM_PFNMAP for, though, because it
> did not
> properly handle vm_normal_page_pmd() etc so far.
> 
Do we ever do a PMD sized COW on VM_IO / VM_PFNMAP
VMAs?

In other words, is this something we should:
- leave out for now?
- fix now?
- fix later?

If we can fix it later, I'll add it to the list.

-- 
All Rights Reversed.