Re: [PATCH] mm/hugetlb: account for allowed nodes when gathering surplus pages

[Muchun Song <muchun.song@linux.dev>]

> On Sep 11, 2026, at 06:20, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> On Thu, 10 Sep 2026 16:48:56 +0800 Muchun Song <muchun.song@linux.dev> wrote:
> 
>>> This fixes hugetlb mappings when, for example, a task runs with
>>> MPOL_BIND on Node 1 while the existing free huge pages are on Node 0.
>>> 
>>> Similar issue also could be found in ltp if the free pages of global pool
>>> reside outside the nodes allowed by the application.
>>> # cd ltp/testcases/kernel/mem/hugetlb/hugemmap/
>>> # numactl --cpunodebind=0 --membind=1 ./hugemmap10
>>> 
>>> Signed-off-by: Huaisheng Ye <yehuaisheng@open-hieco.net>
>> 
>> Acked-by: Muchun Song <muchun.song@linux.dev>
> 
> Should we backport this?
> 
> If so, a Fixes: target would be helpful.

I believe the fix should be e4e574b767ba ("hugetlb: Try to grow hugetlb
pool for MAP_SHARED mappings"). This commit was introduced back in 2007.
Regarding the impact of this issue, I consulted an AI:

Severity: Medium
Impact: valid HugeTLB mappings can be rejected with ENOMEM
Scope: NUMA + cpuset/MPOL_BIND + nr_overcommit_hugepages
Risk: availability/configuration failure, no data corruption


The fact that it has only been triggered after such a long time also
precisely shows how uncommon its configuration is. I expect that
backporting may encounter some conflicts. In the absence of clear user
feedback, I personally suggest not doing a backport.

Of course, as the author of this patch, you could also provide more
information, for example, whether it was discovered as a real issue
in a production environment, so as to decide whether to proceed with
a backport.

Thanks.