Re: [PATCH v3 07/26] x86/mm: introduce mm-local region

Mike Rapoport <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>
On Sun, Jul 26, 2026 at 10:22:40PM +0000, Brendan Jackman wrote:
> Various security features benefit from having process-local address
> mappings within the kernel. Examples include no-direct-map guest_memfd
> [2] and significant optimizations for ASI [1].
> 
> With the currently envisaged usecases, there will be many situations
> where almost no processes have any need for the mm-local region.
> Therefore, avoid its overhead (memory cost of pagetables, alloc/free
> overhead during fork/exit) for processes that don't use it by requiring
> its users to explicitly initialize it via the new mm_local_* API.
> 
> As pointed out by Andy in [0], x86 already has a PGD entry that is local
> to the mm, which is used for the LDT. In a subsequent patch, the LDT
> remap will be unified with the general mm-local region, but to help
> keep the patch to a manageable size, first just introduce the mm-local
> region.
> 
> On 64-bit, give the mm-local region a whole PGD. On 32-bit, just give it
> one PMD. No investigation has been done into whether it's feasible to
> expand the region on 32-bit. Most likely there is no strong usecase for
> that anyway.
> 
> In order to combine the need for an on-demand mm initialisation, with
> the desire to transparently handle propagating mappings to userspace
> under KPTI, the user and kernel pagetables are shared at the highest
> level possible. For PAE that means the PTE table is shared and for
> 64-bit the P4D/PUD. This is implemented by pre-allocating the first
> shared table when the mm-local region is first initialised.
> 
> [0] https://lore.kernel.org/linux-mm/CALCETrXHbS9VXfZ80kOjiTrreM2EbapYeGp68mvJPbosUtorYA@mail.gmail.com/
> [1] https://linuxasi.dev/
> [2] https://lore.kernel.org/all/[email protected]
> Signed-off-by: Brendan Jackman <[email protected]>
> ---
>  arch/x86/Kconfig                        |   2 +
>  arch/x86/include/asm/mmu_context.h      | 118 +++++++++++++++++++++++++++++++-
>  arch/x86/include/asm/pgtable_32_areas.h |   9 ++-
>  arch/x86/include/asm/pgtable_64_types.h |  12 +++-
>  arch/x86/mm/pgtable.c                   |   3 +
>  include/linux/mm.h                      |  13 ++++
>  include/linux/mm_types.h                |   2 +
>  kernel/fork.c                           |   1 +
>  mm/Kconfig                              |   7 ++
>  9 files changed, 161 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index fb298e2191792..3efab3524a6cf 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -132,6 +132,8 @@ config X86
>  	select ARCH_SUPPORTS_LTO_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG_THIN
>  	select ARCH_SUPPORTS_RT
> +	# LDT remap temporarily clashes with mm-local region, can't have both.
> +	select ARCH_SUPPORTS_MM_LOCAL_REGION	if X86_64 || X86_PAE && !MODIFY_LDT_SYSCALL
>  	select ARCH_USE_BUILTIN_BSWAP
>  	select ARCH_USE_CMPXCHG_LOCKREF
>  	select ARCH_USE_MEMTEST
> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
> index ef5b507de34e2..3d4f54673014f 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -8,8 +8,10 @@
>  
>  #include <trace/events/tlb.h>
>  
> +#include <asm/tlb.h>
>  #include <asm/tlbflush.h>
>  #include <asm/paravirt.h>
> +#include <asm/pgalloc.h>
>  #include <asm/debugreg.h>
>  #include <asm/gsseg.h>
>  #include <asm/desc.h>
> @@ -223,10 +225,124 @@ static inline int arch_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
>  	return ldt_dup_context(oldmm, mm);
>  }
>  
> +#ifdef CONFIG_MM_LOCAL_REGION
> +static inline void mm_local_region_free(struct mm_struct *mm)
> +{
> +	if (!mm_local_region_used(mm))
> +		return;
> +
> +	struct mmu_gather tlb;
> +	unsigned long start = MM_LOCAL_BASE_ADDR;
> +	unsigned long end = MM_LOCAL_END_ADDR;
> +
> +	/*
> +	 * Although free_pgd_range() is intended for freeing user
> +	 * page-tables, it also works out for kernel mappings on x86.
> +	 * Use tlb_gather_mmu_fullmm() to avoid confusing the
> +	 * range-tracking logic in __tlb_adjust_range().
> +	 */
> +	tlb_gather_mmu_fullmm(&tlb, mm);
> +	free_pgd_range(&tlb, start, end, start, end);
> +	tlb_finish_mmu(&tlb);
> +
> +	mm_flags_clear(MMF_LOCAL_REGION_USED, mm);
> +}
> +
> +#if defined(CONFIG_MITIGATION_PAGE_TABLE_ISOLATION) && defined(CONFIG_X86_PAE)
> +static inline pmd_t *pgd_to_pmd_walk(pgd_t *pgd, unsigned long va)

There's very similar mm_find_pmd() in mm/rmap.c and I bet a bunch of other
places walk from PGD to PMD and return PMD in the end.

Can we put this function into, say, mm/pgtable-generic.c?
Finding all the places that do such walk and sticking it there should not
be a part of this set IMNHO, but having it in the generic code is a good
start for a future cleanup.

> +{
> +	p4d_t *p4d;
> +	pud_t *pud;
> +
> +	if (pgd->pgd == 0)
> +		return NULL;
> +
> +	p4d = p4d_offset(pgd, va);
> +	if (p4d_none(*p4d))
> +		return NULL;
> +
> +	pud = pud_offset(p4d, va);
> +	if (pud_none(*pud))
> +		return NULL;
> +
> +	return pmd_offset(pud, va);
> +}

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