Re: [PATCH v3 01/26] set_memory: add folio_{zap,restore}_direct_map helpers

[Brendan Jackman]

On Fri Jul 31, 2026 at 5:21 AM UTC, Mike Rapoport wrote:
> On Thu, Jul 30, 2026 at 08:34:57PM +0000, Yosry Ahmed wrote:
>> On Sun, Jul 26, 2026 at 10:22:34PM +0000, Brendan Jackman wrote:
>> > From: Nikita Kalyazin <nikita.kalyazin@xxxxxxxxx>
>> > 
>> > Let's provide folio_{zap,restore}_direct_map helpers as preparation for
>> > supporting removal of the direct map for guest_memfd folios.
>> > In folio_zap_direct_map(), flush TLB to make sure the data is not
>> > accessible.  On some architectures, there may be a double TLB flush
>> > issued because set_direct_map_valid_noflush already performs a flush
>> > internally.
>> > 
>> > The new helpers need to be accessible to KVM on architectures that
>> > support guest_memfd (x86 and arm64).
>> > 
>> > Direct map removal gives guest_memfd the same protection that
>> > memfd_secret does, such as hardening against Spectre-like attacks
>> > through in-kernel gadgets.
>> > 
>> > Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>> > Signed-off-by: Nikita Kalyazin <nikita.kalyazin@xxxxxxxxx>
>> > [Added comment, dropped modified set_direct_map API, added highmem check]
>> > Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
>> > ---
>> >  include/linux/set_memory.h | 13 +++++++++++++
>> >  mm/memory.c                | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>> >  2 files changed, 59 insertions(+)
>> > 
>> > diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
>> > index 3030d9245f5ac..1bf2a15bca118 100644
>> > --- a/include/linux/set_memory.h
>> > +++ b/include/linux/set_memory.h
>> > @@ -40,6 +40,15 @@ static inline int set_direct_map_valid_noflush(struct page *page,
>> >  	return 0;
>> >  }
>> >  
>> > +static inline int folio_zap_direct_map(struct folio *folio)
>> > +{
>> > +	return 0;
>> 
>> Should this return an error (e.g. -EOPNOTSUPP)? Seems like it would
>> silently succeed if the arch doesn't actually support removing from the
>> direct map.
>
> That's the pattern we have now for all set_memory APIs.

Yeah. And I think that's fine, the risk of silent failure is mitigated
by:

#define can_set_direct_map() false

So yes code could call folio_zap_direct_map() directly and get
confusing results on unsupported configs, but that code would be broken
on arm64 regardless (coz it didn't respect can_set_direct_map()), plus
later in this series is:

#ifdef CONFIG_PAGE_ALLOC_UNMAPPED
#define ALLOC_UNMAPPED	       0x2000
#endif

So higher-level code will fail to compile it if uses ALLOC_UNMAPPED on a
completely unsupported config.