Re: [PATCH v1] mm/rmap: fix migration entries being treated as partial unmaps

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] mm/rmap: PMD migration entries still queue folios for
  deferred split
- [Low] mm/rmap: try_to_migrate_one() misses deferred split on last PTE
  unmap
--

commit 685cbbfa9eaed572b053e5452f3d93b8fec2771b
Author: Joanne Koong <joannelkoong@gmail.com>

mm/rmap: fix migration entries being treated as partial unmaps

This commit adds a may_defer_split parameter to __folio_remove_rmap() and
passes false from try_to_migrate_one() when installing PTE migration
entries, preventing temporary migration entries from queueing anonymous
large folios for deferred splitting.

> diff --git a/mm/rmap.c b/mm/rmap.c
> index fa34e1ccbd8f2..e5d17481c0c01 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
[ ... ]
> @@ -1938,7 +1943,8 @@ void folio_remove_rmap_pmd(struct folio *folio, struct page *page,
>  		struct vm_area_struct *vma)
>  {
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -	__folio_remove_rmap(folio, page, HPAGE_PMD_NR, vma, PGTABLE_LEVEL_PMD);
> +	__folio_remove_rmap(folio, page, HPAGE_PMD_NR, vma, PGTABLE_LEVEL_PMD,
> +			    true);
>  #else
>  	WARN_ON_ONCE(true);
>  #endif

[Severity: Medium]
Can replacing a PMD mapping with migration entries still queue a fully
mapped folio for deferred split?

When try_to_migrate_one() replaces a PMD via set_pmd_migration_entry() or
split_huge_pmd_locked(..., true) -> __split_huge_pmd_locked(), both paths
call folio_remove_rmap_pmd(), which unconditionally passes
may_defer_split = true to __folio_remove_rmap().

If the folio is PMD-mapped in a parent process after fork() and the child
has unmapped or CoW-faulted one subpage so its VMA holds 511 PTE mappings,
removing the parent's PMD rmap sees 0 < nr < nr_pmdmapped (or
last && nr < folio_large_nr_pages(folio) under CONFIG_NO_PAGE_MAPCOUNT)
and calls deferred_split_folio(folio, true).  migrate_folio_move() then
propagates PG_partially_mapped to the destination folio, causing the
shrinker to split the migrated THP even though all 512 pages remain mapped
in the parent.

[ ... ]
> @@ -2516,6 +2523,8 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
>  	mmu_notifier_invalidate_range_start(&range);
>  
>  	while (page_vma_mapped_walk(&pvmw)) {
> +		bool may_defer_split = true;
> +
>  		/* PMD-mapped THP migration entry */
>  		if (!pvmw.pte) {
>  			__maybe_unused unsigned long pfn;
> @@ -2772,12 +2781,20 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
>  			 * No need to invalidate here it will synchronize on
>  			 * against the special swap migration pte.
>  			 */
> +
> +			/*
> +			 * The folio only looks partially unmapped while this PTE
> +			 * holds a migration entry, which is later turned back
> +			 * into a mapping. Don't queue it for deferred split.
> +			 */
> +			may_defer_split = false;
>  		}
>  
>  		if (unlikely(folio_test_hugetlb(folio)))
>  			hugetlb_remove_rmap(folio);
>  		else
> -			folio_remove_rmap_pte(folio, subpage, vma);
> +			__folio_remove_rmap(folio, subpage, 1, vma,
> +					    PGTABLE_LEVEL_PTE, may_defer_split);

[Severity: Low]
Does try_to_migrate_one() miss queueing the folio for deferred split when
the last mapped PTE is unmapped via PageHWPoison(subpage) or
pte_unused(pteval)?

Each earlier PTE converted to a migration entry calls
__folio_remove_rmap() with may_defer_split = false, which still decrements
_nr_pages_mapped (and _large_mapcount).  When the final mapped PTE is
genuinely unmapped with may_defer_split = true, _nr_pages_mapped (or
_large_mapcount under CONFIG_NO_PAGE_MAPCOUNT) drops from 1 to 0, so
__folio_remove_rmap() sees the folio as completely unmapped and sets
partially_mapped = false.  Once remove_migration_ptes() restores the
earlier migration entries, the folio is left partially mapped without
PG_partially_mapped set or being queued on deferred_split_lru.

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