Date: Tue, 21 Jul 2026 07:46:54 -0700
From: Breno Leitao <leitao@debian.org>
To: Guillaume Morin <guillaume@morinfr.org>
Cc: linux-mm@kvack.org, muchun.song@linux.dev, 
	Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH] hugetlb: only adjust reservation during unmapping if
 mapcount is 0
Message-ID: <al99cIaOIPriDQKq@gmail.com>
References: <aleRuVBaWu6eTCJb@bender.morinfr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aleRuVBaWu6eTCJb@bender.morinfr.org>
Sender: owner-linux-mm@kvack.org
Precedence: bulk

On Wed, Jul 15, 2026 at 03:57:13PM +0200, Guillaume Morin wrote:
> This patch changes __unmap_hugepage_range() so it now checks the
> mapcount before adjusting the reservation.

Can you please rephrase this in imperative setence.

> Link: https://lore.kernel.org/all/alEJkwn5VlTTH_ZX@bender.morinfr.org/
> Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed")
> Signed-off-by: Guillaume Morin <guillaume@morinfr.org>

Reviewed-by: Breno Leitao <leitao@debian.org>

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 571212b80835..c0167a09a0c4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -5252,7 +5252,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,

There are some comments before this section, that describe this code.

Could a short note be added for the new one, so the intent survives?
Something like "restore only on the last unmap, otherwise the owner
empties its resv map while a child still maps the folio" would do. One
line is enough.

>  		spin_lock_irq(&hugetlb_lock);
>  		if (!h->surplus_huge_pages && __vma_private_lock(vma) &&
> -		    folio_test_anon(folio)) {
> +		    folio_mapcount(folio) == 0 && folio_test_anon(folio)) {
>  			folio_set_hugetlb_restore_reserve(folio);
>  			/* Reservation to be adjusted after the spin lock */
>  			adjust_reservation = true;

For what it is worth, I confirmed the original df7a6d1f6405 case is
preserved: a singly mapped folio still goes 1 -> 0 across
hugetlb_remove_rmap(), so the MADV_DONTNEED restore still fires.

Thanks for the fix,
--breno