Re: [PATCH 0/5] mm: limit pagecache folio refcount

[David Hildenbrand (Arm)]

On 11/5/26 14:10, David Hildenbrand (Arm) wrote:
> Users can create a lot of folio references to pagecache folios, making
> it possible to overflow the refcount of large folios.
> 
> While we knew that one could in theory overflow a folio's refcount, we
> mostly assumed that bad things would happen and it wouldn't go
> unnoticed.
> 
> Not so sure if that is really always the case, and leaving that problem
> unsolved is irresponsible, so let's limit pagecache folio refcounts.
> 
> This is really only relevant for large folios / thps in the page cache.
> With anon folios (including THPs), we should not be
> able to trigger folio refcount overflows (until we get PUD-sized ones ;) ).

Just a note that I don't think anon THP are as really relevant today, at least
for 4k kernels, as one would usually need that so many processes (consuming so
much memory for everything else) that this is mostly irrelevant in practice as
an attack vector.

At least with 512 pages per THP.

The exception might be arm64 with 16k or 64k page size with 2k. (putting aside
that 512M THPs are barely usable in practice).

#processes to overflow the folio refcount

4k kernel: 512 pages per THP: 4m processes (irrelevant in practice)

16k kernel: 2048 pages per THP: 1m processes (mostly irrelevant in practice)

64k kernel: 8192 pages per THP: 256k processes

The 64k case might be the only relevant one, but I think even there all
processes combined would already consume way more than 100 GiB of kernel memory.

If we really care about the latter case we could throw in some cheap checks
during fork() checks.

Handling migration entry restore / swapin would be a bit more nasty, but not
sure if that's really something to worry about in the big scheme of things.

-- 
Cheers,

David