From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BFDF33BBD7 for ; Mon, 3 Aug 2026 22:33:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796399; cv=none; b=UupTYggN5i+dRmjBOypxR6AeIHjReQBMgjhMO/Ez8Xu+S21j1W0ivfUMkOlUXEaxA4JLq0Xjue2KWvF9yQbHwNC6bIuLcD5OddbmZ39WWCwzrWNG9OqAYF7bLGci/vXcFV6DNFUo5ncYgH9tFiWJPEiVjshy0F0fu8XvUlsarfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796399; c=relaxed/simple; bh=hdjPo8YdjUpY1iyQCMTQxN+9FYyXaa1dJ6fBbQ4ExU0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j7p/OLIlbu5KHXwgUfjvtmYfo0v8HwN/+ZuhbaJ+VGvhPv7ddUhqH2vVdZn3zLyUg2ppPv2uErF/96ZNcZ3grL3uAHCAJsZDr+TVZ8ixTIU7B3Lm7k27oIe6Eo3kwjFLcfX59PI8mJs7AwWawQodV8NL2TagYP4Ln3ONWIv4hCI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jhWGubsx; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jhWGubsx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 004941F00A3A; Mon, 3 Aug 2026 22:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785796398; bh=/zBzIQlhYJkUcdP0zgsu/KndrX4arY4rYTrRL6zaSuM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jhWGubsx0hIxnInyYVZYdjDxvK/3LN690IRGX/hPVDQ12pGBceWhjDIr1dr9OY/T1 Q7ayBE7zUnN78znoRQ7vBuB1al3NxIl2si3y3ShSlxUWuq8KR66IypraogmNMc5M5l QU2Xt7XeWsIEtMt4DcjNP4kiyqa47lmGTr5JARpIiycIanibdWK3hzIcum20n+FJPv 9JXWzZbd66GHQpiGGC/dmd72IWkytEsrJAPqIHMsNJV7IFWK0Tp3lWBKGs+QObnU40 vn4F57ofrTv4y9yD0mxitvAB/jYcuUfdAPiXA7LHHjybFg9FxtOl+jmPhi2kvx5smG CHbMsUcn+vFIw== Date: Mon, 3 Aug 2026 22:33:15 +0000 From: Yosry Ahmed To: 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 , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Sean Christopherson Subject: Re: [PATCH v3 08/26] x86/mm: move LDT remap into mm-local region Message-ID: References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-8-6f5729aa9832@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260726-page_alloc-unmapped-v3-8-6f5729aa9832@google.com> On Sun, Jul 26, 2026 at 10:22:41PM +0000, Brendan Jackman wrote: > Now that x86 processes have a general mm-local region, the LDT-specific > management of the higher-level pagetables can mostly be replaced by just > using the generic mm-local API. > > Drop all management of pagetable allocation and freeing; that is now > handled automatically by virtue of the pagetables being in the mm-local > region. > > Drop explicit logic to map LDTs into the user pagetables under PTI; that > also happens automatically for this region. > > Unify the sanity-checking logic between x86_64 and PAE: use the generic > set_memory.c mechanism to walk pagetables. This means the > sanity-checking is slightly more relaxed, since lookup_address_in_pgd() > is more flexible than pgd_to_pmd_walk(), but this seems to be worth it > for the simplified code. It means that ldt.c doesn't have to know about > the exact structure of the mm-local region's pagetables. > > Signed-off-by: Brendan Jackman > --- [..] > diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c > index 40c5bf97dd5cc..685664c1ee770 100644 > --- a/arch/x86/kernel/ldt.c > +++ b/arch/x86/kernel/ldt.c > @@ -186,10 +186,16 @@ static struct ldt_struct *alloc_ldt_struct(unsigned int num_entries) > > #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION > > -static void do_sanity_check(struct mm_struct *mm, > - bool had_kernel_mapping, > - bool had_user_mapping) > +static void sanity_check_ldt_mapping(struct mm_struct *mm) > { > + pgd_t *k_pgd = pgd_offset(mm, LDT_BASE_ADDR); > + pgd_t *u_pgd = kernel_to_user_pgdp(k_pgd); > + unsigned int k_level, u_level; > + bool had_kernel_mapping, had_user_mapping; > + > + had_kernel_mapping = lookup_address_in_pgd(k_pgd, LDT_BASE_ADDR, &k_level); > + had_user_mapping = lookup_address_in_pgd(u_pgd, LDT_BASE_ADDR, &u_level); > + As mentioned in the previous patch, this patch is difficult to review with the current arrangement and patches 7 and 8 can probably be structured in a better way. The unification of sanity_check_ldt_mapping() by using lookup_address_in_pgd() can also be done separately as part of that. > if (mm->context.ldt) { > /* > * We already had an LDT. The top-level entry should already