Re: [PATCH v2 0/2] mm/hugetlb: fix surplus accounting and availability checks during demotion

[Andrew Morton]

On Mon, 31 Aug 2026 21:35:17 +0800 Longlong Xia <xialonglong2025@xxxxxxx> wrote:

> From: Longlong Xia <xialonglong@xxxxxxxxxx>
> 
> This is v2 of the two-patch series fixing surplus accounting and
> availability checks in the hugetlb demote path.
> 
> Patch 1 fixes source hstate accounting when the free folio selected for
> demotion accounts for a surplus page. Patch 2 prevents demotion from
> removing free huge pages that back reservations.
> 
> Both fixes were tested with x86_64 QEMU guests. The commands below use:
> 
>   hstate=/sys/kernel/mm/hugepages/hugepages-1048576kB
> 
> Patch 1: surplus accounting
> 
> A vmemmap restoration failure is difficult to trigger deterministically.
> For this test only, add a one-shot fault injection that makes the first
> attempt to restore the vmemmap of an optimized 1 GiB folio fail:

OK, so hard to hit from userspace but not impossible.

> Patch 2: cap demotion
> 
> This reproducer requires no kernel instrumentation.
> 
> ...
> 
>    Before this fix, the access fails with SIGBUS and leaves:
> 
>      nr=0 surplus=0 free=0 resv=0
> 
>    After this fix, the access succeeds and leaves:
> 
>      nr=1 surplus=0 free=1 resv=0

OK, that's bad behavior.

I asked my friendly neighborhood LLM and was told

: I'd phrase it like this, keeping the stable justification concrete
: without overstating the exact failure mode:
: 
: On architectures where gigantic HugeTLB pages cannot be allocated or
: freed at runtime, memory hot-remove or hwpoison can attempt to dissolve
: a boot-allocated gigantic page.  The lower-level removal helpers
: silently reject such pages, but dissolve_free_hugetlb_folio() continues
: and can free the folio while it is still on the HugeTLB free list.  If
: vmemmap restoration fails, the rollback can additionally add the
: already-listed folio to the free list again.
: 
: This corrupts the HugeTLB free-page state.  The corruption can persist
: beyond the operation which triggered it and be encountered by a later
: HugeTLB allocation, potentially resulting in kernel warnings, crashes
: or memory corruption.  Avoid the corruption by rejecting gigantic pages
: without runtime support before modifying the HugeTLB pool.

So, with a statement like that, I'm thinking that we should backport
these fixes (or something else that fixes these issues!)

Anyway, these are matters for maintainers to consider, please.  For now
I'll get these patches under test.