Re: [PATCH v9 11/15] mm/pagemap: add PAGE_IS_ACCESSED for RWP tracking

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] PAGEMAP_SCAN handles unpopulated pages (pte_none and pmd_none) inconsistently, violating UFFD-WP asynchronous tracking semantics and creating diverging behavior between fast-path, slow-path, and PMD-hole execution flows.
--

commit 6140b14d4a73c9f85a7063bce04ca47dbbf1e064
Author: Kiryl Shutsemau <kas@kernel.org>

mm/pagemap: add PAGE_IS_ACCESSED for RWP tracking

This commit introduces PAGE_IS_ACCESSED for VM_UFFD_RWP VMAs, separating 
read-write protection tracking from the existing PAGE_IS_WRITTEN flag. 
PAGE_IS_WRITTEN is now properly scoped to only report within VM_UFFD_WP VMAs.

> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 5b55c59573a3c..2d724156763d2 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
[ ... ]
> @@ -2863,7 +2888,8 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  		goto flush_and_return;
>  	}
>  
> -	if (!p->arg.category_anyof_mask && !p->arg.category_inverted &&
> +	if (userfaultfd_wp(vma) && !p->arg.category_anyof_mask &&
> +	    !p->arg.category_inverted &&
>  	    p->arg.category_mask == PAGE_IS_WRITTEN &&
>  	    p->arg.return_mask == PAGE_IS_WRITTEN) {
>  		for (addr = start; addr < end; pte++, addr += PAGE_SIZE) {

[Severity: High]
This is a pre-existing issue, but since this condition is being modified,
does PAGEMAP_SCAN handle unpopulated pages inconsistently depending on
the execution path?

When a process uses UFFD-WP asynchronous tracking and calls the ioctl with
category_mask == PAGE_IS_WRITTEN and PM_SCAN_WP_MATCHING, the behavior
seems to diverge.

For a completely unpopulated 2MB range, pagemap_scan_pte_hole() evaluates
against cur_vma_category (which lacks PAGE_IS_WRITTEN) and skips the hole:

fs/proc/task_mmu.c:pagemap_scan_pte_hole() {
	if (!vma || !pagemap_scan_is_interesting_page(p->cur_vma_category, p))
		return 0;
	...
}

However, in a partially populated PMD, this fast-path loop is taken. Since
pte_present() and pte_swp_uffd_any() are false for pte_none, it appears to
output the unpopulated PTE as PAGE_IS_WRITTEN and installs a WP marker.

If the slow path is forced instead, pagemap_page_category() returns 0 for
pte_none, silently skipping it:

fs/proc/task_mmu.c:pagemap_scan_pmd_entry() {
	...
	for (addr = start; addr != end; pte++, addr += PAGE_SIZE) {
		pte_t ptent = ptep_get(pte);
		unsigned long categories = p->cur_vma_category |
					   pagemap_page_category(p, vma, addr, ptent);
	...
}

Could this inconsistency cause data loss during live migration? If an entire
PMD is zapped, the PMD hole path skips it without reporting it as written
or protecting it. Would this result in the migration process not sending
zero pages for the zapped range, retaining stale data on the destination,
and failing to trigger WP faults on future writes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706084805.8400-1-kirill@shutemov.name?part=11