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

[David Hildenbrand (Arm)]

On 11/12/26 23:53, David Hildenbrand (Arm) wrote:
> With large file folios, overflowing the folio mapcount and refcount
> became possible more easily. 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 and a ratelimited warning 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.
> For fault-around, check in next_uptodate_folio() before trying to lock
> the folio.
> 
> Export folio_ref_count_over_limit_slowpath() using EXPORT_SYMBOL_GPL
> right away so modules can use it through try_get_page(), where we will
> use it 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.
> 
> Don't grant access to the admin reserve from kernel threads, from
> interrupt context, where "current" is just the interrupted task, or with
> IRQs disabled, as even unaudited capability checks can take locks.
> 
> 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. Keep the mapping checks explicit and
> separate from reference acquisition: most are expected to disappear when
> we rework the underlying refcounting.
> 
> Check order 0 folios as well for consistency: each
> folio_add_file_rmap*() and folio_dup_file_rmap*() needs a prior check.
> 
> Adjust the check in folio_get() to just check for invalid refcounts and
> drop folio_ref_zero_or_close_to_overflow(): we really don't want
> negative refcounts or negative mapcounts. Convert to VM_WARN_ON_FOLIO as
> we touch it.
> 
> 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.
> 
> Reported-by: Chris Mason <mason@xxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>
> Acked-by: Zi Yan <ziy@xxxxxxxxxx>
> Reviewed-by: Pedro Falcato <pfalcato@xxxxxxx>
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> ---

I'll squash the following into the applied patch.

I will not print the PFN for now; it's something that can be
forced by a user so exposing the PFN makes me a bit uneasy. If we
are ever sure that exposing the PFN is ok we can easily add it.

As I replied, for these stable fixes I will leave the refcount
handling as it is right now. We don't expect negative refcounts 
r mapcount (folio_mapped() is a prime example). I especially don't
want that in stable kernels where we might have older code that
dependes on that.

That part will be reworked and optimized as I'll change the refcount
handling for page table mappings; then we'll be able to drop the
admin reserve and the limits, and just cap+warn once the refcount goes
negative.