Re: [PATCH v2] mm/hugetlb: fix set_max_huge_pages() when there are surplus pages

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 1 Apr 2025 16:23:39 +0800 Jinjiang Tu <tujinjiang@huawei.com> wrote:

> In set_max_huge_pages(), min_count should mean the acquired persistent
> huge pages, but it contains surplus huge pages. It will leads to failing
> to freeing free huge pages for a Node.
> 
> Steps to reproduce:
> 1) create 5 hugetlb folios in Node0
> 2) run a program to use all the hugetlb folios
> 3) echo 0 > nr_hugepages for Node0 to free the hugetlb folios. Thus the 5
> hugetlb folios in Node0 are accounted as surplus.
> 4) create 5 hugetlb folios in Node1
> 5) echo 0 > nr_hugepages for Node1 to free the hugetlb folios
> 
> The result:
>         Node0    Node1
> Total     5         5
> Free      0         5
> Surp      5         5
> 
> We couldn't subtract surplus_huge_pages from min_mount, since free hugetlb
> folios may be surplus due to HVO. In __update_and_free_hugetlb_folio(),
> hugetlb_vmemmap_restore_folio() may fail, add the folio back to pool and
> treat it as surplus. If we directly subtract surplus_huge_pages from
> min_mount, some free folios will be subtracted twice.
> 
> To fix it, check if count is less than the num of free huge pages that
> could be destroyed (i.e., available_huge_pages(h)), and remove hugetlb
> folios if so.
> 
> Since there may exist free surplus hugetlb folios, we should remove
> surplus folios first to make surplus count correct.
> 
> The result with this patch:
>         Node0    Node1
> Total     5         0
> Free      0         0
> Surp      5         0

Thanks.

> Fixes: 9a30523066cd ("hugetlb: add per node hstate attributes")

16 years ago.  How do people feel about a -stable backport?