Re: [PATCH] mm/damon/vaddr: attempt per-vma lock during page table walk

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Inconsistent VMA Filtering (VM_PFNMAP) in damon_va_walk_page_range()
--

commit b5bde92b4c2b28a90660c48f50de91cd04010328
Author: Kefeng Wang <wangkefeng.wang@huawei.com>

mm/damon/vaddr: attempt per-vma lock during page table walk

This commit introduces damon_va_walk_page_range() to optimize DAMON's
virtual address page table walks. It attempts to acquire a per-VMA lock
and proceeds with walk_page_range_vma() if the range is contained within
a single VMA, falling back to the mmap_read_lock and walk_page_range()
otherwise.

> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 1b0ebe3b6951e..eed2ae132a589 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -237,6 +237,32 @@ static void damon_va_update(struct damon_ctx *ctx)
>  	}
>  }
>  
> +static void damon_va_walk_page_range(struct mm_struct *mm, unsigned long start,
> +		unsigned long end, struct mm_walk_ops *ops, void *private)
> +{
> +	struct vm_area_struct *vma;
> +
> +	vma = lock_vma_under_rcu(mm, start);
> +	if (!vma)
> +		goto lock_mmap;
> +
> +	if (end > vma->vm_end) {
> +		vma_end_read(vma);
> +		goto lock_mmap;
> +	}
> +
> +	ops->walk_lock = PGWALK_VMA_RDLOCK_VERIFY;
> +	walk_page_range_vma(vma, start, end, ops, private);
> +	vma_end_read(vma);
> +	return;
> +
> +lock_mmap:
> +	mmap_read_lock(mm);
> +	ops->walk_lock = PGWALK_RDLOCK;
> +	walk_page_range(mm, start, end, ops, private);
> +	mmap_read_unlock(mm);
> +}

Does this code handle VMAs with the VM_PFNMAP flag inconsistently?

In the fallback path using walk_page_range(), the page walker calls
walk_page_test(), which skips VM_PFNMAP VMAs by default since the DAMON
operations structures do not provide a test_walk callback.

However, the fast path uses walk_page_range_vma(), which bypasses
walk_page_test() entirely and directly walks the page range. 

This means that if a queried address range is fully contained within a single
VM_PFNMAP VMA, the page tables will be walked via the fast path. But if the
same VMA is part of a larger range, the mmap lock fallback is triggered and
the VMA is properly skipped.

Can this lead to DAMON improperly modifying PTEs on raw PFN device mappings,
such as clearing the young bit in damon_mkold_pmd_entry(), when taking the
fast path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511132546.1973270-1-wangkefeng.wang@huawei.com?part=1