From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-21.mta1.migadu.com [95.215.58.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D71F47426B for ; Thu, 13 Aug 2026 16:23:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786638236; cv=none; b=DzKJ4kAvDDqpTYaXMwZh1/mX9PpaJXKVE49kNzIuPZtN7lACR+xYGkggjtUHphPGSdcFoBEGlZazyA7vOvYTWYJBGhFGOh1dnkJJlTB2pX5cN9DS2dBc4VTTdtMnNwv7kadiKKcaaxbI+7lClDBIIAPT78mU8naJ+gA4RPr0riI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786638236; c=relaxed/simple; bh=b8g8o1EPbroInUM8DUJk/BET1LeblPQuGgrDZpp4Q4k=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=dmmvPxEaghi7zDXwvv2JBe/tOzHwfyQ6qGhZUpX2fvaOLDjY+hEW40MA0A5lF6YzxFFjsmHZsi+9RC3g8lFTFy14TzA5Ii4ajWfi3pHhaC40ucAsvg6x2AXbwt8RFBMBAAKMTojhLhzZ5FSo3zCQaRUqYGOUbv9czrEyABBi88Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=xD3qSirc; arc=none smtp.client-ip=95.215.58.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="xD3qSirc" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=b8g8o1EPbroInUM8DUJk/BET1LeblPQuGgrDZpp4Q4k=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786638231; v=1; x=1787243031; b=xD3qSircX7iV4urAj/Q6jf8IcQBOyniKXqSSGVVtNhVQQBmXLTpjOWNFPrsFjcjjir4/wTLz YRlKZDY1oJOHgUsVdYXsMJks0e4hyTYqPb656Srao30SlXOl5kxUgUVDmZrzyrgkCMSgeDemJ0B 5ZBIKgY1l4esz8tsEIOb1ZsE= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (77.97.51.77) by smtp.migadu.com with ESMTPS id 394f813be1b9a82f; Thu, 13 Aug 2026 16:23:51 +0000 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 13 Aug 2026 17:23:46 +0100 Message-Id: From: "Brendan Jackman" To: "Yosry Ahmed" , "Brendan Jackman" Cc: "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Mike Rapoport" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , "Kalyazin, Nikita" , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" Subject: Re: [PATCH v3 07/26] x86/mm: introduce mm-local region X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-7-6f5729aa9832@google.com> In-Reply-To: On Mon Aug 3, 2026 at 11:29 PM BST, Yosry Ahmed wrote: ... >> +#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 =3D MM_LOCAL_BASE_ADDR; >> + unsigned long end =3D MM_LOCAL_END_ADDR; > > These declarations should probably go at the beginning of the function. Oops, ack. >> + >> + /* >> + * 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_X= 86_PAE) > > Would it be clearer to have nested #ifdefs instead? > > #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION > > #ifdef CONFIG_X86_PAE > ... > #else /* CONFIG_X86_PAE */ > ... > #endif /* CONFIG_X86_PAE */ > > #else /* CONFIG_MITIGATION_PAGE_TABLE_ISOLATION */ > > #endif /* CONFIG_MITIGATION_PAGE_TABLE_ISOLATION */ > > Maybe not, just thinking out loud. Hm, I wrote it out in the editor and no I don't think it's clearer. I think as the reader it just means you basically have to reconstruct the &&/elif in your head since you need to see this as a "three-headed if" for it to make any sense. ... >> +#elif defined(CONFIG_MITIGATION_PAGE_TABLE_ISOLATION) >> +static inline int mm_local_map_to_user(struct mm_struct *mm) >> +{ >> + pgd_t *pgd; >> + int err; >> + >> + err =3D preallocate_sub_pgd(mm, MM_LOCAL_BASE_ADDR); >> + if (err) >> + return err; >> + >> + pgd =3D pgd_offset(mm, MM_LOCAL_BASE_ADDR); >> + set_pgd(kernel_to_user_pgdp(pgd), *pgd); >> + return 0; >> +} > > The code above bears a lot of similarity to the LDT code removed in > patch 8, and reviewing them separately is annoying. I realize that they > were a single patch in the previous version and Dave complained that it > was too large. > > What if we go a different way: > 1. Move the LDT functions that will be repurposed to mmu_context.h. > 2. Rename the functions to the mm_local_* domain where needed. > 3. Actually perform the switch for LDT to use mm local region. > > Maybe (2) and (3) should be combined, depending on what the git diff > looks like. > > I think this will make the diffs much clearer, for example > mm_local_map_to_user() mainly differ from map_ldt_struct_to_user() in > preallocation. Sounds fine to me, let's try it out and I'll come back here if it turns out to be messy. >> +#else >> +static inline int mm_local_map_to_user(struct mm_struct *mm) >> +{ >> + WARN_ONCE(1, "mm_local_map_to_user() not implemented"); >> + return -EINVAL; >> +} >> +#endif > [..] >> diff --git a/arch/x86/include/asm/pgtable_32_areas.h b/arch/x86/include/= asm/pgtable_32_areas.h >> index 921148b429676..7fccb887f8b33 100644 >> --- a/arch/x86/include/asm/pgtable_32_areas.h >> +++ b/arch/x86/include/asm/pgtable_32_areas.h >> @@ -30,9 +30,14 @@ extern bool __vmalloc_start_set; /* set once high_mem= ory is set */ >> #define CPU_ENTRY_AREA_BASE \ >> ((FIXADDR_TOT_START - PAGE_SIZE*(CPU_ENTRY_AREA_PAGES+1)) & PMD_MASK) >> =20 >> -#define LDT_BASE_ADDR \ >> - ((CPU_ENTRY_AREA_BASE - PAGE_SIZE) & PMD_MASK) >> +/* >> + * On 32-bit the mm-local region is currently completely consumed by th= e LDT >> + * remap. >> + */ >> +#define MM_LOCAL_BASE_ADDR ((CPU_ENTRY_AREA_BASE - PAGE_SIZE) & PMD_MAS= K) >> +#define MM_LOCAL_END_ADDR (MM_LOCAL_BASE_ADDR + PMD_SIZE) >> =20 >> +#define LDT_BASE_ADDR MM_LOCAL_BASE_ADDR >> #define LDT_END_ADDR (LDT_BASE_ADDR + PMD_SIZE) >> =20 >> #define PKMAP_BASE \ >> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/= asm/pgtable_64_types.h >> index 7eb61ef6a185f..1181565966405 100644 >> --- a/arch/x86/include/asm/pgtable_64_types.h >> +++ b/arch/x86/include/asm/pgtable_64_types.h >> @@ -5,8 +5,11 @@ >> #include >> =20 >> #ifndef __ASSEMBLER__ >> +#include >> #include >> #include >> +#include >> +#include >> =20 >> /* >> * These are used to make use of C type-checking.. >> @@ -100,9 +103,12 @@ extern unsigned int ptrs_per_p4d; >> #define GUARD_HOLE_BASE_ADDR (GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT) >> #define GUARD_HOLE_END_ADDR (GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE) >> =20 >> -#define LDT_PGD_ENTRY -240UL >> -#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT) >> -#define LDT_END_ADDR (LDT_BASE_ADDR + PGDIR_SIZE) >> +#define MM_LOCAL_PGD_ENTRY -240UL >> +#define MM_LOCAL_BASE_ADDR (MM_LOCAL_PGD_ENTRY << PGDIR_SHIFT) >> +#define MM_LOCAL_END_ADDR ((MM_LOCAL_PGD_ENTRY + 1) << PGDIR_SHIFT) > > Any reason not keep the current formula (i.e. MM_LOCAL_BASE_ADDR + > PGDIR_SIZE)? Er no I don't see any good reason I changed this. >> + >> +#define LDT_BASE_ADDR MM_LOCAL_BASE_ADDR >> +#define LDT_END_ADDR (LDT_BASE_ADDR + PMD_SIZE) > > Looks like the LDT area was silently changed to PMD_SIZE here. I assume > this is to give the rest of the pgd-mapped address space to the mermap, > but maybe we should call this out explicitly, or do it when the mermap > is introduced (or separately)? Right. This might be a bug that causes us to leak pagetables on some platforms. Haven't checked as it gets fixed in the next commit regardless, but let's just do what you suggested.