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

[David Hildenbrand (Arm)]

On 11/6/26 11:06, Lance Yang wrote:
> 
> On Fri, Nov 06, 2026 at 10:42:17AM +0100, Jose A. Perez de Azpillaga wrote:
>> On 11/5/26 2:10 PM, 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.
>> in mm-new copy_huge_pmd() now does a folio_dup_file_rmap_pmd() at fork,
>> since Konstantin's "mm/huge_memory: copy file THPs at fork like
>> copy_present_ptes() does". doesn't that one need the check too?
> 
> Ah, good catch! My local tree didn't have Konstantin's series [1] yet. And
> right, that path needs a check too I guess :)

So, likely my series will go in first, it fixes a way older problem. I'll tell
Andrew to hold that one off and let me handle it.

-- 
Cheers,

David