Re: [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map

[Mike Rapoport]

On Wed, Jun 03, 2026 at 07:41:34PM +0800, Lance Yang wrote:
> On Wed, Jun 03, 2026 at 01:59:39PM +0300, Mike Rapoport wrote:
> >On Wed, Jun 03, 2026 at 06:46:23PM +0800, Lance Yang wrote:
> >> From: Lance Yang <lance.yang@xxxxxxxxx>
> >> 
> >> secretmem removes the pages backing secretmem mappings from the direct map.
> >> 
> >> Removing one base page from the direct map can split the covering large
> >> mapping down to PTE mappings. Repeated splits can leave more of the direct
> >> map mapped with PTEs, meaning more TLB entries for the same range and
> >> potentially more TLB pressure.
> >> 
> >> So let's try to restore large page mappings whenever secretmem restores a
> >> folio to the direct map.
> >> 
> >> Tested-by: Xueyuan Chen <xueyuan.chen21@xxxxxxxxx>
> >> Signed-off-by: Lance Yang <lance.yang@xxxxxxxxx>
> >> ---
> >>  include/linux/set_memory.h |  6 ++++++
> >>  mm/secretmem.c             | 12 ++++++++++--
> >>  2 files changed, 16 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> >> index 3030d9245f5a..ad2fa414a22d 100644
> >> --- a/include/linux/set_memory.h
> >> +++ b/include/linux/set_memory.h
> >> @@ -58,6 +58,12 @@ static inline bool can_set_direct_map(void)
> >>  #endif
> >>  #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> >>  
> >> +#ifndef arch_try_collapse_direct_map
> >> +static inline void arch_try_collapse_direct_map(struct page *page)
> >> +{
> >> +}
> >> +#endif
> >
> >Did you explore what would it mean to hook collapse_large_pages() into
> >set_direct_map_default_noflush()?
> 
> Good point, I kept it separate on purpose :)
> 
> Putting collapse into set_direct_map_default_noflush() would change the
> semantics of that helper a bit, IMHO.

For x86 default means present + rw + PSE, so yuu can look at it as actually
better enforcing the semantics :)
 
> I would expect arch_try_collapse_direct_map() to also be useful for cases
> where a direct-map permission change could split a large maping first,
> and the user wants to try restoring the large mapping after changing it
> back. One example[1] is making a direct-map range read-only for security,
> which I am also working on :)

I don't think users should care. The users care for particular permissions
of a range in the direct map. It should be up to the architecture to select
most suitable mapping size. The splits are implicit, I don't see why
collapses can't be implicit as well.
 
> [1] https://lore.kernel.org/linux-mm/9979fa87-88ef-4baf-8592-502ff4888085@xxxxxxxxxx/
> 
> Cheers, Lance
> 

-- 
Sincerely yours,
Mike.