From: Yosry Ahmed <yosry@kernel.org>
To: Brendan Jackman <jackmanb@google.com>
Cc: Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Lorenzo Stoakes <ljs@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
x86@kernel.org, Sumit Garg <sumit.garg@oss.qualcomm.com>,
Will Deacon <will@kernel.org>,
rientjes@google.com, "Kalyazin, Nikita" <kalyazin@amazon.co.uk>,
patrick.roy@linux.dev, "Itazuri, Takahiro" <itazur@amazon.co.uk>,
Andy Lutomirski <luto@kernel.org>,
David Kaplan <david.kaplan@amd.com>,
Thomas Gleixner <tglx@kernel.org>,
Patrick Bellasi <derkling@google.com>,
Reiji Watanabe <reijiw@google.com>,
Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v3 04/26] x86/mm: split out preallocate_sub_pgd()
Date: Fri, 31 Jul 2026 22:10:27 +0000 [thread overview]
Message-ID: <am0aplxsh1b16Rch@google.com> (raw)
In-Reply-To: <20260726-page_alloc-unmapped-v3-4-6f5729aa9832@google.com>
On Sun, Jul 26, 2026 at 10:22:37PM +0000, Brendan Jackman wrote:
> This code will be needed elsewhere in a following patch. Split out the
> trivial code move for easy review.
>
> As a side effect, change the logging slightly: instead of directly
> reporting the level of the failure in panic(), show a generic panic
> message, will be preceded by a separate warn that reports the level of
> the failure. This is a simple way to have this helper suit the needs of
> its new user as well as the existing one.
>
> Other than logging, no functional change intended.
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> arch/x86/include/asm/pgalloc.h | 3 +++
> arch/x86/mm/init_64.c | 44 +++++++-----------------------------------
> arch/x86/mm/pgtable.c | 38 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 48 insertions(+), 37 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
> index c88691b15f3c6..2aba6cfabf495 100644
> --- a/arch/x86/include/asm/pgalloc.h
> +++ b/arch/x86/include/asm/pgalloc.h
> @@ -2,6 +2,7 @@
> #ifndef _ASM_X86_PGALLOC_H
> #define _ASM_X86_PGALLOC_H
>
> +#include <linux/printk.h>
> #include <linux/threads.h>
> #include <linux/mm.h> /* for struct page */
> #include <linux/pagemap.h>
> @@ -128,6 +129,8 @@ static inline void __pud_free_tlb(struct mmu_gather *tlb, pud_t *pud,
> ___pud_free_tlb(tlb, pud);
> }
>
> +extern int preallocate_sub_pgd(struct mm_struct *mm, unsigned long addr);
> +
Do we need extern here?
> #if CONFIG_PGTABLE_LEVELS > 4
> static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d)
> {
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index ab4c5a02326f7..ac6688c70872e 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1293,46 +1293,16 @@ static struct kcore_list kcore_vsyscall;
> static void __init preallocate_vmalloc_pages(void)
> {
> unsigned long addr;
> - const char *lvl;
>
> for (addr = VMALLOC_START; addr <= VMEMORY_END; addr = ALIGN(addr + 1, PGDIR_SIZE)) {
> - pgd_t *pgd = pgd_offset_k(addr);
> - p4d_t *p4d;
> - pud_t *pud;
> -
> - lvl = "p4d";
> - p4d = p4d_alloc(&init_mm, pgd, addr);
> - if (!p4d)
> - goto failed;
> -
> - if (pgtable_l5_enabled())
> - continue;
> -
> - /*
> - * The goal here is to allocate all possibly required
> - * hardware page tables pointed to by the top hardware
> - * level.
> - *
> - * 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 = "pud";
> - pud = pud_alloc(&init_mm, p4d, addr);
> - 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");
> }
> -
> - 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);
> }
>
> 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 *vma, 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 = "p4d";
or:
const char *lvl = pgtable_l5_enabled() ? "p4d" : "pud";
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?
Anyway, if we drop lvl here we can drop the gotos, which would be nice.
> + p4d_t *p4d;
> + pud_t *pud;
> +
> + lvl = "p4d";
> + p4d = 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 = "pud";
> + pud = 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.
> + return -ENOMEM;
> +}
> +#endif
>
> --
> 2.54.0
>
next prev parent reply other threads:[~2026-07-31 22:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 22:22 [PATCH v3 00/26] mm: Add ALLOC_UNMAPPED and AS_NO_DIRECT_MAP Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 01/26] set_memory: add folio_{zap,restore}_direct_map helpers Brendan Jackman
2026-07-27 10:33 ` Mike Rapoport
2026-07-29 11:42 ` Brendan Jackman
2026-07-30 20:34 ` Yosry Ahmed
2026-07-31 5:21 ` Mike Rapoport
2026-07-31 11:57 ` Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 02/26] mm/secretmem: make use of folio_{zap,restore}_direct_map Brendan Jackman
2026-07-27 10:40 ` Mike Rapoport
2026-07-26 22:22 ` [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP Brendan Jackman
2026-07-30 21:06 ` Yosry Ahmed
2026-07-31 12:15 ` Brendan Jackman
2026-07-31 19:28 ` Yosry Ahmed
2026-07-26 22:22 ` [PATCH v3 04/26] x86/mm: split out preallocate_sub_pgd() Brendan Jackman
2026-07-31 22:10 ` Yosry Ahmed [this message]
2026-07-26 22:22 ` [PATCH v3 05/26] x86: move PAE PMD preallocation defines to header Brendan Jackman
2026-07-31 23:59 ` Yosry Ahmed
2026-07-26 22:22 ` [PATCH v3 06/26] x86/tlb: Expose some flush function declarations to modules Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 07/26] x86/mm: introduce mm-local region Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 08/26] x86/mm: move LDT remap into " Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 09/26] mm: Create flags arg for __apply_to_page_range() Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 10/26] mm: Add more flags " Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 11/26] x86/mm: introduce the mermap Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 12/26] mm: KUnit tests for " Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 13/26] mm: introduce freetype_t Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 14/26] mm: move migratetype definitions to freetype.h Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 15/26] mm/page_alloc: add support for freetypes with no freelist Brendan Jackman
2026-07-31 14:13 ` Vlastimil Babka (SUSE)
2026-07-26 22:22 ` [PATCH v3 16/26] mm: add definitions for allocating unmapped pages Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 17/26] mm: encode freetype flags in pageblock flags Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 18/26] mm/page_alloc: separate pcplists by freetype flags Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 19/26] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER Brendan Jackman
2026-07-31 14:52 ` Vlastimil Babka (SUSE)
2026-07-26 22:22 ` [PATCH v3 20/26] mm/page_alloc: introduce ALLOC_NOBLOCK Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 21/26] mm/page_alloc: implement FREETYPE_UNMAPPED allocations Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 22/26] mm: Minimal KUnit tests for some new page_alloc logic Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 23/26] mm: Split out NR_FREE_PAGES_BLOCKS_[UN]MAPPED Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 24/26] mm/page_alloc: always direct compact for unmapped allocs Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 25/26] mm: plumb alloc flags into some alloc funcs Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 26/26] mm: add fast path for AS_NO_DIRECT_MAP Brendan Jackman
2026-07-29 11:52 ` [PATCH v3 00/26] mm: Add ALLOC_UNMAPPED and AS_NO_DIRECT_MAP Brendan Jackman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=am0aplxsh1b16Rch@google.com \
--to=yosry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=david@kernel.org \
--cc=derkling@google.com \
--cc=hannes@cmpxchg.org \
--cc=itazur@amazon.co.uk \
--cc=jackmanb@google.com \
--cc=kalyazin@amazon.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luto@kernel.org \
--cc=patrick.roy@linux.dev \
--cc=peterz@infradead.org \
--cc=reijiw@google.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=sumit.garg@oss.qualcomm.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox