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

[David Hildenbrand (Arm)]

On 5/15/26 02:09, Balbir Singh wrote:
> On 4/9/26 17: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".
>>
> 
> Can secretmem folios be truncated? I assume you are referring to
> ftruncate(), I am looking at the setattr implementation of secretmem
> and it does not seem like it can be truncated.

I thought FALLOC_FL_PUNCH_HOLE would work. But indeed, that does not seem to be
wired up.

-- 
Cheers,

David