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

[Huaisheng Ye]

On 9/11/2026 10:41, Muchun Song wrote:
> > On Sep 11, 2026, at 06:20, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, 10 Sep 2026 16:48:56 +0800 Muchun Song <muchun.song@xxxxxxxxx> 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@xxxxxxxxxxxxxx>
> > > Acked-by: Muchun Song <muchun.song@xxxxxxxxx>
> > 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.
We found this defect when doing the hugemmap10 test of LTP, it appears
with a certain probability (5%) in scenarios involving multiple NUMA nodes.
After debugging, I believe its occurrence is related to the location of
the regular huge page pool and the MPOL_BIND strategy used for allocating 
surplus pages.
So I moved to hugetlb-mmap with some simple setup steps to make it reproduce stably.

A more realistic scenario I have in mind is this, user uses huge pages in memory
pooling solutions like CXL memory expander or others, if there are already some 
regular
huge pages locates on the local node, but user wants to restrict application to use
surplus pages from remote nodes — and that's when the failure occurs.

CC linux-cxl.

BRs,
Huaisheng Ye