From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-226.mta1.migadu.com [95.215.58.226]) (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 A12484908C2 for ; Thu, 13 Aug 2026 15:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786635782; cv=none; b=AyPO1GjIml8H9y64RqnMvZjqs52h3zLvlVlhyc7gC0UEPhuc3QWwINWY/AmUSKKUJNPTtnS20xV9/t+XU3muxFAlGTQTWROEeNmh5G5+Ww2ELSlLNvm4FmtnGZ/6pvC8WmsN9YaVVc89rErTMbzrJfsenqXeQKe7OLGwFDNcty4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786635782; c=relaxed/simple; bh=ZrlSwz1sH+GuY7Ux1ESHXiK4jxEOJCDxesFdDcryT9Y=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=JPvKD/qifMGdzNGVP5MIwZIgTE19rBBWmZ+4/EolAHo5PCD2ff5J5w2Igg6l7gQqwRuft1XVbxzdVr9JmpneCSMlUDK6XF+FXtoqs1tlDMpDVMDkAnXU/OtquVrSLS6tEbomAs5JAfroMs3CQg3GJQ1MmESIvplced5lGBy0NF0= 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=l97aQlE3; arc=none smtp.client-ip=95.215.58.226 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="l97aQlE3" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=ZrlSwz1sH+GuY7Ux1ESHXiK4jxEOJCDxesFdDcryT9Y=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786635777; v=1; x=1787240577; b=l97aQlE3ZvWWcPXuKH5FOf1di96Aysd+BgcEYHRPJr4BVzo0BpLnfbxX2/j6sjpb6C5O/orS +MZhejkxX3ityYvW+VTaq0pDyJOS04XmkJ3i677oUT/Pl7qEsELFoPgYkJanNQ7UcHMs403MMc0 nAgIxL+YrXr77qBf3MD9wZSk= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (77.97.51.77) by smtp.migadu.com with ESMTPS id aae37bbb31fee682; Thu, 13 Aug 2026 15:42:56 +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 16:42:55 +0100 Message-Id: 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 04/26] x86/mm: split out preallocate_sub_pgd() From: "Brendan Jackman" To: "Yosry Ahmed" , "Brendan Jackman" X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-4-6f5729aa9832@google.com> In-Reply-To: On Fri Jul 31, 2026 at 11:10 PM BST, Yosry Ahmed wrote: ... >> +extern int preallocate_sub_pgd(struct mm_struct *mm, unsigned long addr= ); >> + > > Do we need extern here? Nope=20 >> - if (!pud) >> - goto failed; >> + if (preallocate_sub_pgd(&init_mm, addr)) { >> + /* >> + * The pages have to be there now or they will be >> + * missing in process page-tables later. >> + */ >> + panic("Failed to pre-allocate pagetables for vmalloc area\n"); >> + } > > Nit: We can probably move this comment above the if block, and drop the > curly braces: > > /* > * The pages have to be there now or they will be missing in > * process page-tables later. > */ > if (preallocate_sub_pgd(&init_mm, addr)) > panic("Failed to pre-allocate pagetables for vmalloc area\n"); > Ack, thanks. >> } >> - >> - return; >> - >> -failed: >> - >> - /* >> - * The pages have to be there now or they will be missing in >> - * process page-tables later. >> - */ >> - panic("Failed to pre-allocate %s pages for vmalloc area\n", lvl); >> } >> =20 >> void __init arch_mm_preinit(void) >> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c >> index f32facdb30354..fdd3709509946 100644 >> --- a/arch/x86/mm/pgtable.c >> +++ b/arch/x86/mm/pgtable.c >> @@ -833,3 +833,41 @@ void arch_check_zapped_pud(struct vm_area_struct *v= ma, pud_t pud) >> /* See note in arch_check_zapped_pte() */ >> VM_WARN_ON_ONCE(!(vma->vm_flags & VM_SHADOW_STACK) && pud_shstk(pud)); >> } >> + >> +#if CONFIG_PGTABLE_LEVELS > 3 >> +/* >> + * Allocate all possibly required hardware page tables pointed to ths > > ^the > >> + * top hardware level. In other words, allocate a p4d on 5-level or a > > allocate p4ds? >> + * pud on 4-level. > > puds? > >> + */ >> +int preallocate_sub_pgd(struct mm_struct *mm, unsigned long addr) >> +{ >> + const char *lvl; > > Nit: > > const char *lvl =3D "p4d"; > > or: > > const char *lvl =3D pgtable_l5_enabled() ? "p4d" : "pud"; This is just maintaining the old way preallocate_vmalloc_pages() was written. > But I am wondering how important this information is here? > > We should be able to tell whether 5-level paging is enabled based on > kernel config and command line. If the information is generally not easy > to get, maybe logging it during boot would generally be useful? Yeah I don't think this is very important, I'm just trying to avoid changing log messages unnecessarily, keepign it aligned with the old preallocate_vmalloc_pages(). For both questions, not strong feelings from me either way, happy to change it or try to keep it the same. > Anyway, if we drop lvl here we can drop the gotos, which would be nice. > >> + p4d_t *p4d; >> + pud_t *pud; >> + >> + lvl =3D "p4d"; >> + p4d =3D p4d_alloc(mm, pgd_offset_pgd(mm->pgd, addr), addr); >> + if (!p4d) >> + goto failed; >> + >> + if (pgtable_l5_enabled()) >> + return 0; >> + >> + /* >> + * On 4-level systems, the P4D layer is folded away and >> + * the above code does no preallocation. Below, go down >> + * to the pud _software_ level to ensure the second >> + * hardware level is allocated on 4-level systems too. >> + */ >> + lvl =3D "pud"; >> + pud =3D pud_alloc(mm, p4d, addr); >> + if (!pud) >> + goto failed; >> + return 0; >> + >> +failed: >> + pr_warn_ratelimited("Failed to preallocate %s\n", lvl); > > Can this possibly fire more than once? IIUC we will panic right after > returning. In the immediate usecase no, but once it's used for mm_local_map_to_user() we do actually handle failure.