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

Mike Rapoport <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>
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]>
> ---
>  include/linux/secretmem.h  |  18 --------
>  mm/secretmem.c             |  46 +++-----------------

Lovely :)
For the secretmem bits

Reviewed-by: Mike Rapoport (Microsoft) <[email protected]>

>  8 files changed, 128 insertions(+), 87 deletions(-)
> 
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 4e8b2b29f6d3e..011f6e34859cc 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -15,6 +15,7 @@
>  #include <linux/bitops.h>
>  #include <linux/hardirq.h> /* for in_interrupt() */
>  #include <linux/hugetlb_inline.h>
> +#include <linux/set_memory.h>
>  
>  struct folio_batch;
>  
> @@ -210,6 +211,7 @@ enum mapping_flags {
>  	AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM = 9,
>  	AS_KERNEL_FILE = 10,	/* mapping for a fake kernel file that shouldn't
>  				   account usage to user cgroups */
> +	AS_NO_DIRECT_MAP = 11,	/* Folios in the mapping are not in the direct map */
>  	/* Bits 16-25 are used for FOLIO_ORDER */
>  	AS_FOLIO_ORDER_BITS = 5,
>  	AS_FOLIO_ORDER_MIN = 16,
> @@ -345,6 +347,9 @@ static inline bool mapping_writeback_may_deadlock_on_reclaim(const struct addres
>  	return test_bit(AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM, &mapping->flags);
>  }
>  
> +static inline unsigned int
> +mapping_max_folio_order(const struct address_space *mapping);
> +
>  static inline gfp_t mapping_gfp_mask(const struct address_space *mapping)
>  {
>  	return mapping->gfp_mask;
> @@ -366,6 +371,24 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask)
>  	m->gfp_mask = mask;
>  }
>  
> +static inline void mapping_set_no_direct_map(struct address_space *mapping)
> +{
> +	WARN_ON(!can_set_direct_map());
> +	/* folio_zap_direct_map() doesn't support large folios. */
> +	WARN_ON(mapping_max_folio_order(mapping));

Can't we use VM_WARN_ON() here?

> +	set_bit(AS_NO_DIRECT_MAP, &mapping->flags);
> +}

...

> +#else
> +static inline int prep_add_unmapped_folio(struct address_space *mapping, struct folio *folio)
> +{
> +	VM_WARN_ON(mapping_no_direct_map(mapping));
> +	return 0;
> +}
> +
> +static inline void prep_remove_unmapped_folio(struct address_space *mapping,
> +					      struct folio *folio)
> +{
> +	VM_WARN_ON(mapping_no_direct_map(mapping));
> +}
> +
> +static inline void prep_remove_unmapped_batch(struct address_space *mapping,
> +					      struct folio_batch *fbatch)
> +{
> +	VM_WARN_ON(mapping_no_direct_map(mapping));
> +}

Heh, that's a lot of WARNings :)
But I can see why you want them :)

> +#endif

-- 
Sincerely yours,
Mike.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.