Re: [PATCH v2] mm/memfd: fix hugetlb reservation accounting in error paths

[Andrew Morton]

On Thu,  3 Sep 2026 11:01:34 +0800 Hongfu Li <hongfu.li@xxxxxxxxx> wrote:

> From: Hongfu Li <lihongfu@xxxxxxxxxx>
> 
> If hugetlb_add_to_page_cache() in memfd_alloc_folio() fails with
> -EEXIST, a concurrent fault has already instantiated the folio in the
> page cache, and the reservation now belongs to that folio. Calling
> hugetlb_unreserve_pages() in that case incorrectly removes the region
> backing the cached folio. A later truncate or inode eviction then passes
> a negative (chg - freed) into hugepage_subpool_put_pages(), corrupting
> subpool and resv_huge_pages accounting.

Ho hum.

I've asked so many times "what are the userspace-visible runtime
effects of this bug".  Nowadays I often just ask Gemini instead.  It
told me:


  Over time, these corrupted counters would leak huge page reservations. 
  Applications using hugetlb memfds would eventually find themselves
  unable to allocate huge pages, receiving unexpected ENOMEM errors even
  though system memory and pool capacities appeared free and healthy.

and

  The corrupted accounting caused hugepage_subpool_put_pages() to
  receive a negative value during a later file truncation or inode
  eviction.

  While this typically manifests as kernel logs (WARN traces or
  badness flags regarding subpool page counts), it could cause
  misbehaved resource tracking that impacts subsequent system
  operations, unmounts, or process teardowns interacting with that
  hugetlb file descriptor.

All of which sounds rather unpleasant, so I suggest a cc:stable here.


To help people understand why we propose a backport and to help others
understand the impact the fix will have upon their system, I'll paste
the above into the changelog.  Please send any necessary corrections.


Please also update your prompts (if using them) to ensure that the
changelogging includes this info in the future.


I'll queue it for testing and shall await maintainer review.