Re: [PATCH 05/15] mm/hugetlb: keep surplus folios when the pool shrinks
From: Gregory Price (Meta)
Date: Fri Nov 13 2026 - 16:47:25 EST
On 2026-10-28 21:13 +0100, David Hildenbrand (Arm) wrote:
> From: Josef Bacik <josef@xxxxxxxxxxxxxx>
>
> Surplus folios are accounted per node. When shrinking the pool,
> set_max_huge_pages() removes free folios through
> remove_pool_hugetlb_folio() and accounts them as persistent folios.
>
> It can select a node whose folios are all surplus and leave its surplus
> count larger than its total count. Free surplus folios can back
> reservations created by gather_surplus_pages().
>
> For example, with nr_overcommit_hugepages = 8 on two nodes:
>
> (node columns show total/free/surplus)
>
> total free surp node0 node1
> mmap() of one page, bound to node 0 1 1 1 1 1 1 0 0 0
> node1/nr_hugepages = 7 8 8 1 1 1 1 7 7 0
> nr_hugepages = 6 7 7 1 0 0 1 7 7 0
> munmap() 7 7 1 0 0 1 7 7 0
> nr_hugepages = 0 1 1 1 0 0 1 1 1 0
>
> After shrinking to six persistent folios, node 0 has no folios but its
> surplus count is still one. Releasing the reservation cannot clear that
> count, and shrinking the pool to zero leaves one free page on node 1.
>
> A later write to node0/nr_hugepages underflows the unsigned per-node
> persistent count: 0 - 1, resulting in allocation of many folios.
>
> Use persistent_huge_pages_node() to skip nodes with no persistent folios,
> as adjust_pool_surplus() does. This also excludes temporary folios.
>
> Fixes: e4e574b767ba ("hugetlb: Try to grow hugetlb pool for MAP_SHARED mappings")
> Cc: stable@xxxxxxxxxx
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> [ david: cleanup code and description ]
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
Reproduced the total=0, surplus=1 issue and subsequent underflow, and
verified this patch fixes the issue.
Tested-by: Gregory Price (Meta) <gourry@xxxxxxxxxx>
--
~Gregory