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

[Hongfu Li <hongfu.li@linux.dev>]

On 9/4/26 4:21 AM, Andrew Morton wrote:
> On Thu,  3 Sep 2026 11:01:34 +0800 Hongfu Li <hongfu.li@linux.dev> wrote:
>
>> From: Hongfu Li <lihongfu@kylinos.cn>
>>
>> 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.


Thanks for the detailed explanation.

I've updated the changelog to include the userspace-visible effects
and long-term impact as suggested.

Would you prefer that I send a v2 now, or should I wait for maintainer
feedback first?

-- 
Best regards,
Hongfu