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

[Kiryl Shutsemau <kas@kernel.org>]

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?

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.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov