Skip to contentSkip to conversation

FAILED: patch "[PATCH] hugetlb: only adjust reservation during unmapping if mapcount" failed to apply to 6.12-stable tree

PATCH Applied [email protected] 3 participants 3 messages Sep 3 – Sep 6

Subsystems (3)
Stable branch Memory management HugeTLB
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 5120b1e048d48596ffaec1a8412012a91adba73b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026090356-destiny-subject-4d56@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..'

Possible dependencies:

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 5120b1e048d48596ffaec1a8412012a91adba73b Mon Sep 17 00:00:00 2001
From: Guillaume Morin <[email protected]>
Date: Tue, 28 Jul 2026 21:29:03 +0200
Subject: [PATCH] hugetlb: only adjust reservation during unmapping if mapcount
is 0

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 +6 -2
index 49bf325325c0..7d14511c20ad 100644
@@ -5218,6 +5218,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	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_gather *tlb, struct vm_area_struct *vma,
 
 		/*
 		 * 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_gather *tlb, struct vm_area_struct *vma,
 
 		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;
#1 lore raw

PATCH 1/1 hugetlb: only adjust reservation during unmapping if mapcount

This is a backport of 5120b1e048d48596ffaec1a8412012a91adba73b which failed to apply to the 6.12 branch

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]>
(cherry picked from commit 5120b1e048d48596ffaec1a8412012a91adba73b)
Signed-off-by Guillaume Morin <[email protected]>
---
 mm/hugetlb.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
mm/hugetlb.c +6 -2
index e910ed0c43d0..185faeaf5c08 100644
@@ -5523,6 +5523,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	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));

@@ -5613,7 +5614,10 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 
 		/*
 		 * 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.
 		 */

@@ -5621,7 +5625,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 
 		spin_lock_irq(&hugetlb_lock);
 		if (!h->surplus_huge_pages && __vma_private_lock(vma) &&
-		    folio_test_anon(page_folio(page))) {
+		    !folio_mapped(page_folio(page)) && folio_test_anon(page_folio(page))) {
 			folio_set_hugetlb_restore_reserve(page_folio(page));
 			/* Reservation to be adjusted after the spin lock */
 			adjust_reservation = true;
Signature · 5 lines
2.39.1


-- 
Guillaume Morin <[email protected]>
maintainer Applied
#2 lore raw

Re: [PATCH 6.12.y] hugetlb: only adjust reservation during unmapping if mapcount

Quoted 6 lines

This is a backport of 5120b1e048d48596ffaec1a8412012a91adba73b which failed to apply to the 6.12 branch

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

Queued for 6.12, thanks.

Signature · 2 lines
Thanks,
Sasha