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

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

On 11/6/26 21:54, David Hildenbrand (Arm) wrote:
> 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.
> 

Okay, I ended up splitting it up. A bit nsaty now that fuse will require an
exported symbol.

>>
>> 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.

Ok, the noaudit definitely seems to be the right thing. But getting overlayfs +
fuse oddities done "better", I am using has_capability_noaudit(current,
CAP_SYS_RESOURCE) now.

Hoping that is the right thing to use now ... review appreciated.

-- 
Cheers,

David