Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP

On Sun, Jul 26, 2026 at 10:22:36PM +0000, Brendan Jackman wrote:
> From: Patrick Roy <[email protected]>
> 
> Add AS_NO_DIRECT_MAP for mappings where direct map entries of folios are
> set to not present. Currently, mappings that match this description are
> secretmem mappings (memfd_secret()). Later, some guest_memfd
> configurations will also fall into this category.
> 
> Reject this new type of mappings in all locations that currently reject
> secretmem mappings, on the assumption that if secretmem mappings are
> rejected somewhere, it is precisely because of an inability to deal with
> folios without direct map entries, and then make memfd_secret() use
> AS_NO_DIRECT_MAP on its address_space to drop its special
> vma_is_secretmem()/secretmem_mapping() checks.
> 
> Use a new flag instead of overloading AS_INACCESSIBLE (which is already
> set by guest_memfd) because not all guest_memfd mappings will end up
> being direct map removed (e.g. in pKVM setups, parts of guest_memfd that
> can be mapped to userspace should also be GUP-able, and generally not
> have restrictions on who can access it).
> 
> Signed-off-by: Patrick Roy <[email protected]>
> Signed-off-by: Nikita Kalyazin <[email protected]>
> [Moved zapping to page cache; removed review tags]
> Signed-off-by: Brendan Jackman <[email protected]>
> ---
[..]
>  /**
>   * filemap_remove_folio - Remove folio from page cache.
>   * @folio: The folio.
> @@ -260,6 +309,8 @@ void filemap_remove_folio(struct folio *folio)
>  		inode_lru_list_add(mapping->host);
>  	spin_unlock(&mapping->host->i_lock);
>  
> +	prep_remove_unmapped_folio(mapping, folio);

Does this miss callers that call __filemap_remove_folio() directly?

We can't just move the call into __filemap_remove_folio() as it will
later include a TLB shootdown and (at least) some of the callers have
IRQs disabled.

> +
>  	filemap_free_folio(mapping, folio);
>  }