From: "Brendan Jackman" <brendan.jackman@linux.dev>
To: "Yosry Ahmed" <yosry@kernel.org>,
"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: Thu, 13 Aug 2026 16:42:55 +0100 [thread overview]
Message-ID: <DKNXIWKP5KIO.1YT877KQJN0IF@linux.dev> (raw)
In-Reply-To: <am0aplxsh1b16Rch@google.com>
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
>> - 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);
>> }
>>
>> 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";
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 = "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.
In the immediate usecase no, but once it's used for
mm_local_map_to_user() we do actually handle failure.
next prev parent reply other threads:[~2026-08-13 15:42 UTC|newest]
Thread overview: 90+ 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-08-07 0:02 ` Sean Christopherson
2026-08-07 0:13 ` Yosry Ahmed
2026-08-07 0:19 ` Sean Christopherson
2026-08-07 0:29 ` Yosry Ahmed
2026-08-07 14:26 ` Sean Christopherson
2026-08-07 18:12 ` Yosry Ahmed
2026-08-07 18:49 ` Sean Christopherson
2026-08-07 19:39 ` Yosry Ahmed
2026-08-07 22:44 ` Sean Christopherson
2026-08-07 22:48 ` Yosry Ahmed
2026-08-08 13:56 ` Brendan Jackman
2026-08-10 21:39 ` Yosry Ahmed
2026-08-10 21:46 ` Sean Christopherson
2026-08-13 15:32 ` Brendan Jackman
2026-08-13 17:25 ` Ackerley Tng
2026-08-02 16:10 ` Mike Rapoport
2026-08-08 0:19 ` 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
2026-08-13 15:42 ` Brendan Jackman [this message]
2026-08-02 16:13 ` Mike Rapoport
2026-08-13 15:46 ` Brendan Jackman
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-08-13 15:49 ` Brendan Jackman
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-08-02 16:27 ` Mike Rapoport
2026-08-13 16:10 ` Brendan Jackman
2026-08-03 22:29 ` Yosry Ahmed
2026-08-13 16:23 ` Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 08/26] x86/mm: move LDT remap into " Brendan Jackman
2026-08-03 22:33 ` Yosry Ahmed
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-08-04 0:08 ` Yosry Ahmed
2026-08-13 16:40 ` Brendan Jackman
2026-07-26 22:22 ` [PATCH v3 11/26] x86/mm: introduce the mermap Brendan Jackman
2026-08-02 16:40 ` Mike Rapoport
2026-08-13 16:44 ` Brendan Jackman
2026-08-04 18:38 ` Yosry Ahmed
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-08-04 22:23 ` Yosry Ahmed
2026-08-04 23:02 ` Yosry Ahmed
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-08-04 19:53 ` Yosry Ahmed
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-08-03 9:20 ` Vlastimil Babka (SUSE)
2026-08-04 21:50 ` Yosry Ahmed
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-08-03 9:18 ` Vlastimil Babka (SUSE)
2026-08-04 23:41 ` Yosry Ahmed
2026-08-07 0:05 ` Yosry Ahmed
2026-08-04 23:53 ` Yosry Ahmed
2026-08-05 16:13 ` Yosry Ahmed
2026-08-07 0:16 ` Yosry Ahmed
2026-08-12 21:26 ` Yosry Ahmed
2026-07-26 22:22 ` [PATCH v3 22/26] mm: Minimal KUnit tests for some new page_alloc logic Brendan Jackman
2026-08-03 9:30 ` Vlastimil Babka (SUSE)
2026-07-26 22:22 ` [PATCH v3 23/26] mm: Split out NR_FREE_PAGES_BLOCKS_[UN]MAPPED Brendan Jackman
2026-08-03 9:32 ` Vlastimil Babka (SUSE)
2026-07-26 22:22 ` [PATCH v3 24/26] mm/page_alloc: always direct compact for unmapped allocs Brendan Jackman
2026-08-03 9:44 ` Vlastimil Babka (SUSE)
2026-08-06 23:29 ` Yosry Ahmed
2026-07-26 22:22 ` [PATCH v3 25/26] mm: plumb alloc flags into some alloc funcs Brendan Jackman
2026-08-03 9:52 ` Vlastimil Babka (SUSE)
2026-07-26 22:22 ` [PATCH v3 26/26] mm: add fast path for AS_NO_DIRECT_MAP Brendan Jackman
2026-08-08 0:06 ` Yosry Ahmed
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=DKNXIWKP5KIO.1YT877KQJN0IF@linux.dev \
--to=brendan.jackman@linux.dev \
--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=yosry@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.