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

[Andrew Morton <akpm@linux-foundation.org>]

On Wed,  8 Apr 2026 18:46:47 -0700 John Hubbard <jhubbard@nvidia.com> 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.

How significant is the slowdown?

> 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.