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

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

On 11/6/26 13:38, Kiryl Shutsemau wrote:
> On Thu, Nov 05, 2026 at 02:10:10PM +0100, 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.
>>
>> That's 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.
>>
>> 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.
>>
>> While the refcount checks are not required for order 0 folios, let's
>> just add them 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.
>>
>> 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 | 33 +++++++++++++++++++++++++++++++++
>>  mm/filemap.c       |  6 ++++++
>>  mm/huge_memory.c   | 24 ++++++++++++++++++++++--
>>  mm/memory.c        | 23 ++++++++++++++++++++---
>>  mm/migrate.c       | 11 +++++++++++
>>  mm/userfaultfd.c   |  4 ++++
>>  6 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index a2dd76cc5bbfe..79ae8fc0d6bb4 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -8,6 +8,7 @@
>>  #include <linux/gfp.h>
>>  #include <linux/pgalloc_tag.h>
>>  #include <linux/bug.h>
>> +#include <linux/capability.h>
>>  #include <linux/list.h>
>>  #include <linux/mmzone.h>
>>  #include <linux/rbtree.h>
>> @@ -2228,6 +2229,38 @@ vm_fault_t finish_fault(struct vm_fault *vmf);
>>  #define folio_ref_zero_or_close_to_overflow(folio) \
>>  	((unsigned int) folio_ref_count(folio) + 127u <= 127u)
>>  
>> +/* Leave separate reserves for administrators and concurrent reference gains. */
>> +#define FOLIO_REF_COUNT_LIMIT		(INT_MAX - (1U << 26))
>> +#define FOLIO_REF_COUNT_ADMIN_LIMIT	(INT_MAX - (1U << 25))
>> +
>> +/**
>> + * folio_ref_count_over_limit - Check whether to refuse more folio references.
>> + * @folio: The folio.
>> + *
>> + * Relevant for large pagecache folios (!hugetlb). For these, we have to check
>> + * before adding page table mappings or other significant refcount users whether
>> + * we are close to our folio ref count limit, to avoid overflows.
>> + *
>> + * Checking this for other folios does no harm but is mostly unnecessary.
>> + *
>> + * This check is an approximation; we leave some headroom such that concurrent
>> + * increments, batches and temporary references are not a problem.
>> + *
>> + * Return: True if the caller should refuse additional references, false
>> + * otherwise.
>> + */
>> +static inline bool folio_ref_count_over_limit(const struct folio *folio)
>> +{
>> +	const unsigned int ref_count = folio_ref_count(folio);
>> +
>> +	if (likely(ref_count < FOLIO_REF_COUNT_LIMIT))
>> +		return false;
>> +	if (ref_count >= FOLIO_REF_COUNT_ADMIN_LIMIT)
>> +		return true;
>> +	/* Background threads must not consume admin reserves. */
>> +	return (current->flags & PF_KTHREAD) || !capable(CAP_SYS_RESOURCE);
>> +}
>> +
>>  /**
>>   * folio_get - Increment the reference count on a folio.
>>   * @folio: The folio.
> 
> Does the slow path need to be inline at all 15 call sites, GUP-fast
> among them?

It's not a lot of code. Do we really care?

E.g., in gup.c, the compiler is free to not inline into each of the two callsites.

> 
> Maybe only leave the likely() check in inline and move the rest into a
> function call?
> 
> Something like:
> 
> static inline bool folio_ref_count_over_limit(const struct folio *folio)
> {
>         const unsigned int ref_count = folio_ref_count(folio);
> 
>         if (likely(ref_count < FOLIO_REF_COUNT_LIMIT))
>                 return false;
>         return __folio_ref_count_over_limit(ref_count);
> }
> 
> bool __folio_ref_count_over_limit(unsigned int ref_count)
> {
>         if (ref_count >= FOLIO_REF_COUNT_ADMIN_LIMIT)
>                 return true;
>         /* Background threads must not consume admin reserves */
>         if (current->flags & PF_KTHREAD)
>                 return true;
>         return !capable(CAP_SYS_RESOURCE);
> }
> 
> Also, should this be capable_noaudit()? I am not sure a refused
> reference should leave an audit record. cap_vm_enough_memory() checks
> the admin reserve with CAP_OPT_NOAUDIT.
> 

Not an expert, but capable_noaudit() sounds good.

Not sure if that fully resolves sashiko's complaint in the last commit.

Thanks!

-- 
Cheers,

David