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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/17/26 19:00, Rik van Riel wrote:
> __access_remote_vm() holds mmap_read_lock() for the whole transfer. On
> large machines with large multi-threaded applications, the mmap_lock
> is often contended due to mixed accesses from readers and writers, like
> mmap and munmap. When a lock holder gets stuck, system monitoring software
> can get stuck behind that, resulting in a failure to log that the system
> is in trouble.
> 
> Take the per-VMA lock in __access_remote_vm() when the access falls
> entirely within a single VMA. Fall back to the mmap lock when the access
> crosses a VMA boundary, or when the page cannot be reached under the
> per-VMA lock: a dropped fault, a userfaultfd VMA, a hard error, or memory
> with no struct page that has to go through vma->vm_ops->access().
> 
> The bulk of the work is a new gup helper. __access_remote_vm() needs a
> single page from a VMA it has already looked up and locked, faulting it in
> when necessary, under either lock.

Yes, much better.

> 
> 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.

> 
> 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.

> 
> get_user_page_vma() now returns that page normally. Raw PFNs with no struct
> page still reach ->access() under the mmap lock, as before.
> 
> The series is arranged as:


It will take me a bit to dig into the details; I'll be out the remainder of the
week. But the general direction sounds good.

-- 
Cheers,

David