Re: [PATCH] mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios

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

On 4/9/26 17:05, Zi Yan wrote:
> On 9 Apr 2026, at 3:52, David Hildenbrand (Arm) wrote:
> 
>> On 4/9/26 03:46, John Hubbard wrote:
>>> Since commit f002882ca369 ("mm: merge folio_is_secretmem() and
>>> folio_fast_pin_allowed() into gup_fast_folio_allowed()"),
>>> gup_fast_folio_allowed() falls back to the slow path for any order-0
>>> folio with a NULL mapping when CONFIG_SECRETMEM=y. This causes a
>>> performance regression for drivers that allocate pages with alloc_page()
>>> and insert them into VMAs via vm_insert_page(). These pages legitimately
>>> have a NULL folio->mapping, but they cannot be secretmem pages.
>>>
>>> Secretmem pages are always added to the secretmem inode's page cache via
>>> filemap_add_folio(), which sets folio->mapping to the inode's i_mapping.
>>> A folio with a NULL mapping can never be a secretmem folio. The
>>> NULL-mapping check was intended to handle truncated file-backed pages (a
>>> reject_file_backed concern), not secretmem detection.
>>>
>>> When only check_secretmem is true (and reject_file_backed is false), a
>>> NULL mapping is sufficient to prove the folio is not secretmem, so the
>>> fast path can proceed.
>>
>> Hm, what if secretmem folio just got truncated? I hate to rely on some
>> handling in the caller to detect truncation differently during GUP-fast,
>> but this function returning "true".
>>
>> Zi is working on a way to distinguish folios from non-folio things: that
>> we can identify whatever was added through vm_insert_page().
> 
> The idea is to give every allocated page a NotRmappable page_type and
> 1) let page_rmappable_folio() remove the page_type by setting mapcount
> to 0, since page_type overlaps with mapcount;
> 2) allow callers of alloc_page*() to change page_type from NotRmappable
> to other types.

Could we instead just set the special type in vm_insert_page(), after
verifying that it does not have any other type?

> 
> After these, rmappable folios with any order is a folio without any
> page_type. HugeTLB is an exception, but rmap code has special handling
> for them, so it should be fine.
> 
> I have a draft[1], but have not had time to refresh it yet. I am planning
> to work on this after my two other jobs (make READ_ONLY_THP_FOR_FS enabled
> for all FS with large folio support and ensure ->private is 0 for tail pages).
> 
> [1] https://github.com/x-y-z/linux-dev/tree/remove_mapcount_for_non_folio-2026-02-16-23-27
> 
>>
>> Because that's really the key problem here: vm_insert_page() pages are
>> not actually folios, they just look like a folio today, but looking at
>> fields like ->mapping does not make any sense.
> 
> Based on my understanding of some callers of alloc_page()/get_free_pages(),
> vm_insert_page(), they use GFP_COMP to get a compound page and vm_insert_page()
> individual pages of the compound page. These pages might be pinned.
> During past THP cabal meeting, we discussed about it if
> 1. we should disallow such uses and only allow order-0 allocations, or

Right.

> 2. we need a new type like new_type_folio for them and the type does not
> have folio fields except ->pincount.

Right.

-- 
Cheers,

David