Re: [PATCH v2 3/4] mm/migrate: add tracepoint for folios unmapped during migration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Returning ACTION_AGAIN from inside the PTE loop in `mlock_pte_range` causes double-counting of `mlock_count` for folios processed earlier in the same PMD.
--

--- Patch [3]: [PATCH v2 3/4] mm/migrate: add tracepoint for folios unmapped during migration ---
commit 66d2b427e02176d2cc56e534e84b38ba838aacba
Author: Wandun Chen <chenwandun@lixiang.com>

mm/migrate: add tracepoint for folios unmapped during migration

This commit adds the mm_migrate_unmap_folio tracepoint to try_to_migrate_one().
The tracepoint records the PFN, address, and flags when a folio's mapping is
replaced by a migration entry, aiding observation of mlocked folios under
migration.

> diff --git a/mm/rmap.c b/mm/rmap.c
> index d99499ae338f9..d911e6ca62e5b 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2723,6 +2723,10 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
>  			hugetlb_remove_rmap(folio);
>  		else
>  			folio_remove_rmap_pte(folio, subpage, vma);
> +
> +		trace_mm_migrate_unmap_folio(folio_pfn(folio), address,
> +					     folio->flags.f, vma->vm_flags);
> +

[Severity: High]
When try_to_migrate_one() replaces a mapping with a migration entry here, can
this cause a double-counting issue during concurrent mlock() calls?

If mlock_pte_range() encounters this migration entry midway through a PMD
range, it sets walk->action = ACTION_AGAIN and returns 0:

mm/mlock.c:mlock_pte_range() {
	...
	for (pte = start_pte; addr != end; pte++, addr += PAGE_SIZE) {
		ptent = ptep_get(pte);
		if (!pte_present(ptent)) {
			if (unlikely((vma->vm_flags & VM_LOCKED) &&
			    !compaction_allow_unevictable() &&
			    softleaf_is_migration(softleaf_from_pte(ptent)))) {
				pte_unmap_unlock(start_pte, ptl);
				migration_entry_wait(vma->vm_mm, pmd, addr);
				walk->action = ACTION_AGAIN;
				return 0;
			}
			continue;
		}
		...
		if (vma->vm_flags & VM_LOCKED)
			mlock_folio(folio);
	...
}

Because the page walker handles ACTION_AGAIN by restarting from the beginning
of the PMD without advancing addr, will the folios processed earlier in this
PMD be processed again?

Could this cause mlock_folio() to artificially inflate their mlock_count for
each duplicate pass, permanently stranding the memory in the unevictable LRU?

>  		if (vma->vm_flags & VM_LOCKED)
>  			mlock_drain_local();
>  		folio_put(folio);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707125925.3725177-1-chenwandun1@gmail.com?part=3