Re: [PATCH 14/15] RFC: mm/hugetlb: account restored reservations before freeing folios

[David Hildenbrand (Arm)]

On 10/28/26 21:13, David Hildenbrand (Arm) wrote:
> Unmapping an anonymous folio restores its private VMA reservation
> immediately, but the global reservation count is only restored when the
> folio is freed.
> 
> If any folio reference delays freeing, closing the VMA or refaulting can
> decrement resv_huge_pages before it was incremented. This can underflow
> the counter or hide another mapping's reservation, allowing an unreserved
> allocation to consume its backing.
> 
> Increment resv_huge_pages when restoring the reserve map instead. Detach
> the folio from its subpool, since the restored reservation now owns that
> charge. Leave the restore-reserve flag clear so freeing the folio does not
> repeat the accounting. The folio only becomes free after its last reference
> is dropped.
> 
> Reservations can now temporarily outnumber free folios. Clamp available
> pages to zero in that case, including for demotion, and limit surplus
> releases to available pages so they cannot remove backing for remaining
> reservations.
> 
> Restore reservations even when surplus pages exist. free_huge_folio()
> already retains pages needed to back them. It is unclear why that was
> really added. The comment about i_mmap_lock_write can go as well, that
> doesn't really help for anonymous folios.
> 
> Two existing problems remain:
> 
> 1) Anonymous hugetlb migration temporarily drops the mapcount. A concurrent
>    unmap can observe zero and restore a reservation even though migration
>    will reinstall a mapping. i_mmap_lock_write() does not protect anonymous
>    folio mapcounts, so it does not prevent this race. This change fixes the
>    resulting counter underflow, but leaves premature restoration possible,
>    leading to (2). Maybe that anon_vma lock can help?
> 
> 2) A fault can allocate a replacement folio using the restored
>    reservation before the old folio is freed. Repeated vmsplice(),
>    MADV_DONTNEED and refaults can retain multiple folios for one
>    reservation and consume pages backing other reservations. This was
>    already possible; counter accounting is now fixed, but early reuse
>    remains. Removing the surplus check also allows it after unmaps that
>    previously skipped restoration.
> 
> Deferring reservation-map restoration until the final put is tricky:
> free_huge_folio() has no VMA context to update the private reserve map, and
> that VMA may already have been destroyed.
> 
> Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed")
> Cc: stable@xxxxxxxxxxxxxxx
> Reported-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> ---

This is the current updated patch I have: