Skip to contentSkip to conversation

mm/rmap: make folio unmap batching safe and support partial batches

PATCH Applied Lance Yang 4 participants 4 messages Jun 27, 2025 – Jul 16, 2025

Subsystems (3)
Memory management RISC-V MM rmap
lore
Share & tools
lore

Lance Yang

author
#0 lore raw

PATCH 1/1 mm/rmap: make folio unmap batching safe and support partial batches

From: Lance Yang <[email protected]>

As pointed out by David[1], the batched unmap logic in try_to_unmap_one() can read past the end of a PTE table if a large folio is mapped starting at the last entry of that table.

So let's fix the out-of-bounds read by refactoring the logic into a new helper, folio_unmap_pte_batch().

The new helper now correctly calculates the safe number of pages to scan by limiting the operation to the boundaries of the current VMA and the PTE table.

In addition, the "all-or-nothing" batching restriction is removed to support partial batches. The reference counting is also cleaned up to use folio_put_refs().

[1] https://lore.kernel.org/linux-mm/[email protected]

Fixes 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation")
Suggested-by David Hildenbrand <[email protected]>
Suggested-by Barry Song <[email protected]>
Signed-off-by Lance Yang <[email protected]>
---
 mm/rmap.c | 46 ++++++++++++++++++++++++++++------------------
 1 file changed, 28 insertions(+), 18 deletions(-)
mm/rmap.c +28 -18
index fb63d9256f09..1320b88fab74 100644
@@ -1845,23 +1845,32 @@ void folio_remove_rmap_pud(struct folio *folio, struct page *page,
 #endif
 }
 
-/* We support batch unmapping of PTEs for lazyfree large folios */
-static inline bool can_batch_unmap_folio_ptes(unsigned long addr,
-			struct folio *folio, pte_t *ptep)
+static inline unsigned int folio_unmap_pte_batch(struct folio *folio,
+			struct page_vma_mapped_walk *pvmw,
+			enum ttu_flags flags, pte_t pte)
 {
 	const fpb_t fpb_flags = FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY;
-	int max_nr = folio_nr_pages(folio);
-	pte_t pte = ptep_get(ptep);
+	unsigned long end_addr, addr = pvmw->address;
+	struct vm_area_struct *vma = pvmw->vma;
+	unsigned int max_nr;
+
+	if (flags & TTU_HWPOISON)
+		return 1;
+	if (!folio_test_large(folio))
+		return 1;
 
+	/* We may only batch within a single VMA and a single page table. */
+	end_addr = pmd_addr_end(addr, vma->vm_end);
+	max_nr = (end_addr - addr) >> PAGE_SHIFT;
+
+	/* We only support lazyfree batching for now ... */
 	if (!folio_test_anon(folio) || folio_test_swapbacked(folio))
-		return false;
+		return 1;
 	if (pte_unused(pte))
-		return false;
-	if (pte_pfn(pte) != folio_pfn(folio))
-		return false;
+		return 1;
 
-	return folio_pte_batch(folio, addr, ptep, pte, max_nr, fpb_flags, NULL,
-			       NULL, NULL) == max_nr;
+	return folio_pte_batch(folio, addr, pvmw->pte, pte, max_nr, fpb_flags,
+			       NULL, NULL, NULL);
 }
 
 /*

@@ -2024,9 +2033,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 			if (pte_dirty(pteval))
 				folio_mark_dirty(folio);
 		} else if (likely(pte_present(pteval))) {
-			if (folio_test_large(folio) && !(flags & TTU_HWPOISON) &&
-			    can_batch_unmap_folio_ptes(address, folio, pvmw.pte))
-				nr_pages = folio_nr_pages(folio);
+			nr_pages = folio_unmap_pte_batch(folio, &pvmw, flags, pteval);
 			end_addr = address + nr_pages * PAGE_SIZE;
 			flush_cache_range(vma, address, end_addr);
 

@@ -2206,13 +2213,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 			hugetlb_remove_rmap(folio);
 		} else {
 			folio_remove_rmap_ptes(folio, subpage, nr_pages, vma);
-			folio_ref_sub(folio, nr_pages - 1);
 		}
 		if (vma->vm_flags & VM_LOCKED)
 			mlock_drain_local();
-		folio_put(folio);
-		/* We have already batched the entire folio */
-		if (nr_pages > 1)
+		folio_put_refs(folio, nr_pages);
+
+		/*
+		 * If we are sure that we batched the entire folio and cleared
+		 * all PTEs, we can just optimize and stop right here.
+		 */
+		if (nr_pages == folio_nr_pages(folio))
 			goto walk_done;
 		continue;
 walk_abort:
Signature · 1 line
2.49.0
#1 lore raw
Quoted 18 lines · Lance Yang

From: Lance Yang <[email protected]>

As pointed out by David[1], the batched unmap logic in try_to_unmap_one() can read past the end of a PTE table if a large folio is mapped starting at the last entry of that table.

So let's fix the out-of-bounds read by refactoring the logic into a new helper, folio_unmap_pte_batch().

The new helper now correctly calculates the safe number of pages to scan by limiting the operation to the boundaries of the current VMA and the PTE table.

In addition, the "all-or-nothing" batching restriction is removed to support partial batches. The reference counting is also cleaned up to use folio_put_refs().

Quoted 6 lines

[1] https://lore.kernel.org/linux-mm/[email protected]

Fixes 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation")
Suggested-by David Hildenbrand <[email protected]>
Suggested-by Barry Song <[email protected]>
Signed-off-by Lance Yang <[email protected]>

I'd prefer changing the subject to something like
"Fix potential out-of-bounds page table access during batched unmap"

Supporting partial batching is a cleanup-related benefit of this fix. It's worth mentioning that the affected cases are quite rare, since MADV_FREE typically performs split_folio().

Also, we need to Cc stable.

Thanks
Barry

reviewer
#2 lore raw
Quoted 21 lines · Barry Song
Quoted 20 lines · Lance Yang

From: Lance Yang <[email protected]>

As pointed out by David[1], the batched unmap logic in try_to_unmap_one() can read past the end of a PTE table if a large folio is mapped starting at the last entry of that table.

So let's fix the out-of-bounds read by refactoring the logic into a new helper, folio_unmap_pte_batch().

The new helper now correctly calculates the safe number of pages to scan by limiting the operation to the boundaries of the current VMA and the PTE table.

In addition, the "all-or-nothing" batching restriction is removed to support partial batches. The reference counting is also cleaned up to use folio_put_refs().

[1] https://lore.kernel.org/linux-mm/[email protected]

Quoted 7 lines
Quoted 4 lines
Fixes 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation")
Suggested-by David Hildenbrand <[email protected]>
Suggested-by Barry Song <[email protected]>
Signed-off-by Lance Yang <[email protected]>

I'd prefer changing the subject to something like
"Fix potential out-of-bounds page table access during batched unmap"

Yep, that's much better.

Quoted 4 lines

Supporting partial batching is a cleanup-related benefit of this fix. It's worth mentioning that the affected cases are quite rare, since MADV_FREE typically performs split_folio().

Yeah, it would be quite rare in practice ;)

Quoted 2 lines

Also, we need to Cc stable.

Thanks! Will do.

CI Applied
#3 lore raw
In reply to Lance Yang
This patch was applied to riscv/linux.git (fixes) by Andrew Morton <[email protected]>:

Hello:

This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <[email protected]>:

Quoted 10 lines · On Fri, 27 Jun 2025 10:52:14 +0800 you wrote:

From: Lance Yang <[email protected]>

As pointed out by David[1], the batched unmap logic in try_to_unmap_one() can read past the end of a PTE table if a large folio is mapped starting at the last entry of that table.

So let's fix the out-of-bounds read by refactoring the logic into a new helper, folio_unmap_pte_batch().

[...]

Here is the summary with links:
- [1/1] mm/rmap: make folio unmap batching safe and support partial batches

    https://git.kernel.org/riscv/c/ddd05742b45b

You are awesome, thank you!

Signature · 2 lines
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html