Re: [PATCH v2 1/5] mm: limit pagecache folio refcount when mapping pages

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/10/26 03:52, Zi Yan wrote:
> On Sat Nov 7, 2026 at 5:23 PM EST, David Hildenbrand (Arm) wrote:
>> With large file folios, overflowing the folio mapcount and refcount
>> became possible. For anon folios it is currently not really an issue:
>> each large anon folio can only be mapped once into a process; on 4k
>> kernels it would be more processes than usually allowed on a system, and
>> on 16k or 64k kernels the processes alone would consume hundreds of GiB.
>> Something to be sorted out at some point, but it's not as urgent.
>>
>> Being able to overflow the refcount is not really big news, but it's about
>> time that we do something about it because some modern technology might
>> find ways to abuse it :)
>>
>> One of the enablers for that was commit ddc58f27f9ee ("mm: drop tail page
>> refcounting"), however, file thp support was added later.
>>
>> File folios can be mapped multiple times into the same process, allowing
>> for processes to hold many references to the same folio.
>>
>> As a short-term solution, let's introduce two folio refcount limits:
>> one for ordinary consumers and one for admins. Leave some headroom
>> before the refcount goes negative, which we really don't want (having
>> the mapcount go negative is also not expected).
>>
>> Start reporting SIGBUS if we run into limits. When restoring mappings
>> from migration entries, instead zap the pte/pmd entry. We allow for
>> slightly exceeding the limit to keep things simpler.
>>
>> During fork(), prefer not copying page table entries over failing fork.
>> Export __folio_ref_count_over_limit() right away as that will be needed
>> from fuse code next. Use has_capability_noaudit(current, CAP_SYS_RESOURCE),
>> so filesystem credential overrides do not affect access to the admin
>> reserve, and to not generate auditing messages simply because we access
>> optional reserves.
>>
>> This is far from ideal, but better than all easy alternatives we can
>> backport comfortably. For now it fixes the big problem: letting
>> the refcount (+mapcount) go negative and cause trouble.
>>
>> This is only a temporary fix, we'll follow up with something better.
>>
>> Check order 0 folios as well for consistency: each
>> folio_add_file_rmap*() and folio_dup_file_rmap*() needs a prior check.
>>
>> Also, just document -EHWPOISON for copy_present_ptes() while at it.
>>
>> Note: When zapping file migration entries, uffd-wp is preserved using PTE
>> markers, but uffd-rwp protection is lost because there is no corresponding
>> marker. try_to_unmap() already has the same problem when unmapping file
>> folios, so we'll happily ignore it.
>>
>> Note2: For now we don't let migration or PTE table collapse exceed any
>> limits. Admins can always refault, and if we are already operating in
>> admin reserves, something is already off.
>>
>> Reported-by: Chris Mason <mason@kernel.org>
>> Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
>> Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
>> Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>>  include/linux/mm.h | 30 ++++++++++++++++++++++++++++++
>>  mm/filemap.c       |  6 ++++++
>>  mm/huge_memory.c   | 29 +++++++++++++++++++++++++++--
>>  mm/memory.c        | 35 +++++++++++++++++++++++++++++++----
>>  mm/migrate.c       | 11 +++++++++++
>>  mm/userfaultfd.c   |  4 ++++
>>  mm/util.c          | 12 ++++++++++++
>>  7 files changed, 121 insertions(+), 6 deletions(-)
>>
> 
> LGTM. I wonder if we want to add a VM_WARN_ON_ONCE() refcount check in
> __folio_add_file_rmap() and __folio_dup_file_rmap(), so that no new
> caller will not miss the refcount limit handling. That also requires a
> reproducer for verification, but it might be hard to trigger all
> possible code path. Anyway,
> 

As it is valid to expand into the headroom above the limit, we could really only
check for invalid refcounts (<= 0) there.

We do have a folio_ref_zero_or_close_to_overflow() check in folio_get(). Likely
I should just replace that by a check for <= 0, as that's really what we want to
avoid.

> Acked-by: Zi Yan <ziy@nvidia.com>

Thanks!
-- 
Cheers,

David