Re: [PATCH 1/4] mm: mincore: try per-VMA lock firstly and use walk_page_range_vma()

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

On 6/17/26 10:26, Kefeng Wang wrote:
> The mincore syscall currently takes mmap lock for the entire
> duration of the VMA lookup and page table walk. This creates
> a global contention point with page faults and other mmap_lock
> holders in multi-threaded applications.
> 
> The mincore is a read-only operation that only queries page
> residency from a single VMA, making it an ideal candidate for
> per-VMA locking, so try per-vma lock firstly and use the
> walk_page_range_vma() in do_mincore() to eliminates an unnecessary
> find_vma() lookup.
> 
> Unlike walk_page_range(), walk_page_range_vma() does not call
> walk_page_test(), which handles VM_PFNMAP by invoking ->pte_hole()
> to skip the page table walk. Without this check, PFNMAP PTEs
> would be treated as present by mincore_pte_range(), changing
> the returned residency status. Handle VM_PFNMAP explicitly in
> do_mincore() to preserve the original behavior.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---

I think you should first add a patch that converts do_mincore() to just use
walk_page_range_vma() -- which is what your patch series "mm: convert to
walk_page_range_vma() to eliminate find_vma()" wants to achieve.

Which would already be an improvement :)

Regarding the per-VMA lock, given that we already drop the mmap lock after each
VMA, concurrent mremap() would already be able to return funky results.

So that should be just fine.

-- 
Cheers,

David