Skip to contentSkip to conversation

hugetlb-only-adjust-reservation-during-unmapping-if-mapcount-is-0.patch removed from -mm tree

merged mm-stable Andrew Morton 1 participant 1 message Aug 25 Stable branch

lore
Share & tools
lore

Andrew Morton

author tree notice Applied
#0 lore raw

The quilt patch titled
Subject: hugetlb: only adjust reservation during unmapping if mapcount is 0
has been removed from the -mm tree. Its filename was
hugetlb-only-adjust-reservation-during-unmapping-if-mapcount-is-0.patch

This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

------------------------------------------------------
From: Guillaume Morin <[email protected]>
Subject: hugetlb: only adjust reservation during unmapping if mapcount is 0
Date: Tue, 28 Jul 2026 21:29:03 +0200

Since df7a6d1f6405, __unmap_hugepage_range can adjust reservations. In the case of folio mapped in both a parent and a child, if the parent unmaps the range first, the reservation adjustment will result in an underflow of the reserved count. Once the child unmaps the range, the count is restored. Change __unmap_hugepage_range() to check the mapcount before adjusting the reservation.

Link https://lore.kernel.org/all/[email protected]/ open here
Link https://lore.kernel.org/[email protected] open here
Fixes df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed")
Signed-off-by Guillaume Morin <[email protected]>
Reviewed-by Breno Leitao <[email protected]>
Reviewed-by Rik van Riel <[email protected]>
Cc Muchun Song <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Oscar Salvador <[email protected]>
Cc <[email protected]>
Signed-off-by Andrew Morton <[email protected]>

---

 mm/hugetlb.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
mm/hugetlb.c renamed from mm/hugetlb.c~hugetlb-only-adjust-reservation-during-unmapping-if-mapcount-is-0 +6 -2
@@ -5218,6 +5218,7 @@ void __unmap_hugepage_range(struct mmu_g
 	bool adjust_reservation;
 	unsigned long last_addr_mask;
 
+	i_mmap_assert_write_locked(vma->vm_file->f_mapping);
 	WARN_ON(!is_vm_hugetlb_page(vma));
 	BUG_ON(start & ~huge_page_mask(h));
 	BUG_ON(end & ~huge_page_mask(h));

@@ -5309,7 +5310,10 @@ void __unmap_hugepage_range(struct mmu_g
 
 		/*
 		 * Restore the reservation for anonymous page, otherwise the
-		 * backing page could be stolen by someone.
+		 * backing page could be stolen by someone. Restore only on the
+		 * last unmap, otherwise the owner could empty its resv map
+		 * while the folio is still mapped by a child. Note that holding
+		 * i_mmap_lock_write is needed to check the number of mappings.
 		 * If there we are freeing a surplus, do not set the restore
 		 * reservation bit.
 		 */

@@ -5317,7 +5321,7 @@ void __unmap_hugepage_range(struct mmu_g
 
 		spin_lock_irq(&hugetlb_lock);
 		if (!h->surplus_huge_pages && __vma_private_lock(vma) &&
-		    folio_test_anon(folio)) {
+		    !folio_mapped(folio) && folio_test_anon(folio)) {
 			folio_set_hugetlb_restore_reserve(folio);
 			/* Reservation to be adjusted after the spin lock */
 			adjust_reservation = true;

_

Patches currently in -mm which might be from [email protected] are