Re: [PATCH v2 0/3] mm: __access_remote_vm with per-VMA lock

[Lorenzo Stoakes]

On Wed, Jun 24, 2026 at 09:50:50PM -0400, Rik van Riel wrote:
> Sometimes processes can get stuck with the mmap_lock held for
> a long time. This slows down, and can even prevent system monitoring
> tools from assessing and logging the situation, because they themselves
> end up getting stuck on the mmap_lock.
>
> However, with the introduction of per-VMA locks, we can improve the
> reliability of system monitoring, and generally speed up __access_remote_vm
> under mmap_loc contention, by adding a fast path that does not require
> the process-wide mmap_lock.
>
> This fast path is only compiled in and used when it is safe to do so,
> meaning a kernel with per-VMA locks, RCU pgae table freeing, the VMA
> is not hugetlbfs, iomap, pfnmap, etc...
>
> v2:
>  - simplify the code, which should be ok because these copies are < PAGE_SIZE
>  - clean up the code
>  - fix locking wrt tlb_remove_table_sync_one()
>  - hopefully address all the other comments

Please always send a diffstat in your cover letter by the way.

I noticed you didn't do this elsewhere also, so please adjust your tooling to do
this :) (git format-patch --cover-letter does this by default).

Thanks, Lorenzo