* [PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h
2025-08-18 2:02 [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss Harry Yoo
@ 2025-08-18 2:02 ` Harry Yoo
2025-08-18 7:47 ` David Hildenbrand
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
` (2 subsequent siblings)
3 siblings, 1 reply; 24+ messages in thread
From: Harry Yoo @ 2025-08-18 2:02 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, David Hildenbrand,
Gwan-gyeong Mun, Aneesh Kumar K . V, Uladzislau Rezki,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Qi Zheng, Ard Biesheuvel, Thomas Huth, John Hubbard,
Ryan Roberts, Peter Xu, Dev Jain, Bibo Mao, Anshuman Khandual,
Joerg Roedel, x86, linux-kernel, linux-arch, linux-mm, Harry Yoo,
stable, Kiryl Shutsemau
Move ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to
linux/pgtable.h so that they can be used outside of vmalloc and ioremap.
Cc: <stable@vger.kernel.org>
Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
Acked-by: Kiryl Shutsemau <kas@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
include/linux/pgtable.h | 16 ++++++++++++++++
include/linux/vmalloc.h | 16 ----------------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 4c035637eeb7..ba699df6ef69 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1467,6 +1467,22 @@ static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned
}
#endif
+/*
+ * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values
+ * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings()
+ * needs to be called.
+ */
+#ifndef ARCH_PAGE_TABLE_SYNC_MASK
+#define ARCH_PAGE_TABLE_SYNC_MASK 0
+#endif
+
+/*
+ * There is no default implementation for arch_sync_kernel_mappings(). It is
+ * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK
+ * is 0.
+ */
+void arch_sync_kernel_mappings(unsigned long start, unsigned long end);
+
#endif /* CONFIG_MMU */
/*
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index fdc9aeb74a44..2759dac6be44 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -219,22 +219,6 @@ extern int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
int vmap_pages_range(unsigned long addr, unsigned long end, pgprot_t prot,
struct page **pages, unsigned int page_shift);
-/*
- * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values
- * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings()
- * needs to be called.
- */
-#ifndef ARCH_PAGE_TABLE_SYNC_MASK
-#define ARCH_PAGE_TABLE_SYNC_MASK 0
-#endif
-
-/*
- * There is no default implementation for arch_sync_kernel_mappings(). It is
- * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK
- * is 0.
- */
-void arch_sync_kernel_mappings(unsigned long start, unsigned long end);
-
/*
* Lowlevel-APIs (not for driver use!)
*/
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h Harry Yoo
@ 2025-08-18 7:47 ` David Hildenbrand
0 siblings, 0 replies; 24+ messages in thread
From: David Hildenbrand @ 2025-08-18 7:47 UTC (permalink / raw)
To: Harry Yoo, Andrew Morton, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, Gwan-gyeong Mun,
Aneesh Kumar K . V, Uladzislau Rezki, Liam R . Howlett,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Qi Zheng,
Ard Biesheuvel, Thomas Huth, John Hubbard, Ryan Roberts, Peter Xu,
Dev Jain, Bibo Mao, Anshuman Khandual, Joerg Roedel, x86,
linux-kernel, linux-arch, linux-mm, stable, Kiryl Shutsemau
On 18.08.25 04:02, Harry Yoo wrote:
> Move ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to
> linux/pgtable.h so that they can be used outside of vmalloc and ioremap.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
> Acked-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Reviewed-by: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> ---
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
2025-08-18 2:02 [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss Harry Yoo
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h Harry Yoo
@ 2025-08-18 2:02 ` Harry Yoo
2025-08-18 7:48 ` David Hildenbrand
` (3 more replies)
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Harry Yoo
2025-08-18 7:50 ` [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss David Hildenbrand
3 siblings, 4 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-18 2:02 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, David Hildenbrand,
Gwan-gyeong Mun, Aneesh Kumar K . V, Uladzislau Rezki,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Qi Zheng, Ard Biesheuvel, Thomas Huth, John Hubbard,
Ryan Roberts, Peter Xu, Dev Jain, Bibo Mao, Anshuman Khandual,
Joerg Roedel, x86, linux-kernel, linux-arch, linux-mm, Harry Yoo,
stable, Kiryl Shutsemau
Introduce and use {pgd,p4d}_populate_kernel() in core MM code when
populating PGD and P4D entries for the kernel address space.
These helpers ensure proper synchronization of page tables when
updating the kernel portion of top-level page tables.
Until now, the kernel has relied on each architecture to handle
synchronization of top-level page tables in an ad-hoc manner.
For example, see commit 9b861528a801 ("x86-64, mem: Update all PGDs for
direct mapping and vmemmap mapping changes").
However, this approach has proven fragile for following reasons:
1) It is easy to forget to perform the necessary page table
synchronization when introducing new changes.
For instance, commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory
savings for compound devmaps") overlooked the need to synchronize
page tables for the vmemmap area.
2) It is also easy to overlook that the vmemmap and direct mapping areas
must not be accessed before explicit page table synchronization.
For example, commit 8d400913c231 ("x86/vmemmap: handle unpopulated
sub-pmd ranges")) caused crashes by accessing the vmemmap area
before calling sync_global_pgds().
To address this, as suggested by Dave Hansen, introduce _kernel() variants
of the page table population helpers, which invoke architecture-specific
hooks to properly synchronize page tables. These are introduced in a new
header file, include/linux/pgalloc.h, so they can be called from common code.
They reuse existing infrastructure for vmalloc and ioremap.
Synchronization requirements are determined by ARCH_PAGE_TABLE_SYNC_MASK,
and the actual synchronization is performed by arch_sync_kernel_mappings().
This change currently targets only x86_64, so only PGD and P4D level
helpers are introduced. Currently, these helpers are no-ops since no
architecture sets PGTBL_{PGD,P4D}_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK.
In theory, PUD and PMD level helpers can be added later if needed by
other architectures. For now, 32-bit architectures (x86-32 and arm) only
handle PGTBL_PMD_MODIFIED, so p*d_populate_kernel() will never affect
them unless we introduce a PMD level helper.
Cc: <stable@vger.kernel.org>
Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Kiryl Shutsemau <kas@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
include/linux/pgalloc.h | 24 ++++++++++++++++++++++++
include/linux/pgtable.h | 13 +++++++------
mm/kasan/init.c | 12 ++++++------
mm/percpu.c | 6 +++---
mm/sparse-vmemmap.c | 6 +++---
5 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 include/linux/pgalloc.h
diff --git a/include/linux/pgalloc.h b/include/linux/pgalloc.h
new file mode 100644
index 000000000000..290ab864320f
--- /dev/null
+++ b/include/linux/pgalloc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PGALLOC_H
+#define _LINUX_PGALLOC_H
+
+#include <linux/pgtable.h>
+#include <asm/pgalloc.h>
+
+static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
+ p4d_t *p4d)
+{
+ pgd_populate(&init_mm, pgd, p4d);
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED)
+ arch_sync_kernel_mappings(addr, addr);
+}
+
+static inline void p4d_populate_kernel(unsigned long addr, p4d_t *p4d,
+ pud_t *pud)
+{
+ p4d_populate(&init_mm, p4d, pud);
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED)
+ arch_sync_kernel_mappings(addr, addr);
+}
+
+#endif /* _LINUX_PGALLOC_H */
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index ba699df6ef69..2b80fd456c8b 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1469,8 +1469,8 @@ static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned
/*
* Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values
- * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings()
- * needs to be called.
+ * and let generic vmalloc, ioremap and page table update code know when
+ * arch_sync_kernel_mappings() needs to be called.
*/
#ifndef ARCH_PAGE_TABLE_SYNC_MASK
#define ARCH_PAGE_TABLE_SYNC_MASK 0
@@ -1954,10 +1954,11 @@ static inline bool arch_has_pfn_modify_check(void)
/*
* Page Table Modification bits for pgtbl_mod_mask.
*
- * These are used by the p?d_alloc_track*() set of functions an in the generic
- * vmalloc/ioremap code to track at which page-table levels entries have been
- * modified. Based on that the code can better decide when vmalloc and ioremap
- * mapping changes need to be synchronized to other page-tables in the system.
+ * These are used by the p?d_alloc_track*() and p*d_populate_kernel()
+ * functions in the generic vmalloc, ioremap and page table update code
+ * to track at which page-table levels entries have been modified.
+ * Based on that the code can better decide when page table changes need
+ * to be synchronized to other page-tables in the system.
*/
#define __PGTBL_PGD_MODIFIED 0
#define __PGTBL_P4D_MODIFIED 1
diff --git a/mm/kasan/init.c b/mm/kasan/init.c
index ced6b29fcf76..8fce3370c84e 100644
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -13,9 +13,9 @@
#include <linux/mm.h>
#include <linux/pfn.h>
#include <linux/slab.h>
+#include <linux/pgalloc.h>
#include <asm/page.h>
-#include <asm/pgalloc.h>
#include "kasan.h"
@@ -191,7 +191,7 @@ static int __ref zero_p4d_populate(pgd_t *pgd, unsigned long addr,
pud_t *pud;
pmd_t *pmd;
- p4d_populate(&init_mm, p4d,
+ p4d_populate_kernel(addr, p4d,
lm_alias(kasan_early_shadow_pud));
pud = pud_offset(p4d, addr);
pud_populate(&init_mm, pud,
@@ -212,7 +212,7 @@ static int __ref zero_p4d_populate(pgd_t *pgd, unsigned long addr,
} else {
p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
pud_init(p);
- p4d_populate(&init_mm, p4d, p);
+ p4d_populate_kernel(addr, p4d, p);
}
}
zero_pud_populate(p4d, addr, next);
@@ -251,10 +251,10 @@ int __ref kasan_populate_early_shadow(const void *shadow_start,
* puds,pmds, so pgd_populate(), pud_populate()
* is noops.
*/
- pgd_populate(&init_mm, pgd,
+ pgd_populate_kernel(addr, pgd,
lm_alias(kasan_early_shadow_p4d));
p4d = p4d_offset(pgd, addr);
- p4d_populate(&init_mm, p4d,
+ p4d_populate_kernel(addr, p4d,
lm_alias(kasan_early_shadow_pud));
pud = pud_offset(p4d, addr);
pud_populate(&init_mm, pud,
@@ -273,7 +273,7 @@ int __ref kasan_populate_early_shadow(const void *shadow_start,
if (!p)
return -ENOMEM;
} else {
- pgd_populate(&init_mm, pgd,
+ pgd_populate_kernel(addr, pgd,
early_alloc(PAGE_SIZE, NUMA_NO_NODE));
}
}
diff --git a/mm/percpu.c b/mm/percpu.c
index d9cbaee92b60..a56f35dcc417 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -3108,7 +3108,7 @@ int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
#endif /* BUILD_EMBED_FIRST_CHUNK */
#ifdef BUILD_PAGE_FIRST_CHUNK
-#include <asm/pgalloc.h>
+#include <linux/pgalloc.h>
#ifndef P4D_TABLE_SIZE
#define P4D_TABLE_SIZE PAGE_SIZE
@@ -3134,13 +3134,13 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
if (pgd_none(*pgd)) {
p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
- pgd_populate(&init_mm, pgd, p4d);
+ pgd_populate_kernel(addr, pgd, p4d);
}
p4d = p4d_offset(pgd, addr);
if (p4d_none(*p4d)) {
pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
- p4d_populate(&init_mm, p4d, pud);
+ p4d_populate_kernel(addr, p4d, pud);
}
pud = pud_offset(p4d, addr);
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 41aa0493eb03..dbd8daccade2 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -27,9 +27,9 @@
#include <linux/spinlock.h>
#include <linux/vmalloc.h>
#include <linux/sched.h>
+#include <linux/pgalloc.h>
#include <asm/dma.h>
-#include <asm/pgalloc.h>
#include <asm/tlbflush.h>
#include "hugetlb_vmemmap.h"
@@ -229,7 +229,7 @@ p4d_t * __meminit vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node)
if (!p)
return NULL;
pud_init(p);
- p4d_populate(&init_mm, p4d, p);
+ p4d_populate_kernel(addr, p4d, p);
}
return p4d;
}
@@ -241,7 +241,7 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node)
void *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
if (!p)
return NULL;
- pgd_populate(&init_mm, pgd, p);
+ pgd_populate_kernel(addr, pgd, p);
}
return pgd;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
@ 2025-08-18 7:48 ` David Hildenbrand
2025-08-18 9:02 ` kernel test robot
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: David Hildenbrand @ 2025-08-18 7:48 UTC (permalink / raw)
To: Harry Yoo, Andrew Morton, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, Gwan-gyeong Mun,
Aneesh Kumar K . V, Uladzislau Rezki, Liam R . Howlett,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Qi Zheng,
Ard Biesheuvel, Thomas Huth, John Hubbard, Ryan Roberts, Peter Xu,
Dev Jain, Bibo Mao, Anshuman Khandual, Joerg Roedel, x86,
linux-kernel, linux-arch, linux-mm, stable, Kiryl Shutsemau
On 18.08.25 04:02, Harry Yoo wrote:
> Introduce and use {pgd,p4d}_populate_kernel() in core MM code when
> populating PGD and P4D entries for the kernel address space.
> These helpers ensure proper synchronization of page tables when
> updating the kernel portion of top-level page tables.
>
> Until now, the kernel has relied on each architecture to handle
> synchronization of top-level page tables in an ad-hoc manner.
> For example, see commit 9b861528a801 ("x86-64, mem: Update all PGDs for
> direct mapping and vmemmap mapping changes").
>
> However, this approach has proven fragile for following reasons:
>
> 1) It is easy to forget to perform the necessary page table
> synchronization when introducing new changes.
> For instance, commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory
> savings for compound devmaps") overlooked the need to synchronize
> page tables for the vmemmap area.
>
> 2) It is also easy to overlook that the vmemmap and direct mapping areas
> must not be accessed before explicit page table synchronization.
> For example, commit 8d400913c231 ("x86/vmemmap: handle unpopulated
> sub-pmd ranges")) caused crashes by accessing the vmemmap area
> before calling sync_global_pgds().
>
> To address this, as suggested by Dave Hansen, introduce _kernel() variants
> of the page table population helpers, which invoke architecture-specific
> hooks to properly synchronize page tables. These are introduced in a new
> header file, include/linux/pgalloc.h, so they can be called from common code.
>
> They reuse existing infrastructure for vmalloc and ioremap.
> Synchronization requirements are determined by ARCH_PAGE_TABLE_SYNC_MASK,
> and the actual synchronization is performed by arch_sync_kernel_mappings().
>
> This change currently targets only x86_64, so only PGD and P4D level
> helpers are introduced. Currently, these helpers are no-ops since no
> architecture sets PGTBL_{PGD,P4D}_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK.
>
> In theory, PUD and PMD level helpers can be added later if needed by
> other architectures. For now, 32-bit architectures (x86-32 and arm) only
> handle PGTBL_PMD_MODIFIED, so p*d_populate_kernel() will never affect
> them unless we introduce a PMD level helper.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Acked-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> ---
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
2025-08-18 7:48 ` David Hildenbrand
@ 2025-08-18 9:02 ` kernel test robot
2025-08-18 10:41 ` Harry Yoo
2025-08-21 9:35 ` [PATCH] mm: fix KASAN build error due to p*d_populate_kernel() Harry Yoo
2025-08-22 2:07 ` [PATCH v3] " Harry Yoo
3 siblings, 1 reply; 24+ messages in thread
From: kernel test robot @ 2025-08-18 9:02 UTC (permalink / raw)
To: Harry Yoo; +Cc: oe-kbuild-all
Hi Harry,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/master]
[also build test ERROR on linus/master v6.17-rc2 next-20250818]
[cannot apply to akpm-mm/mm-everything tip/x86/core tip/x86/mm tip/auto-latest dennis-percpu/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Harry-Yoo/mm-move-page-table-sync-declarations-to-linux-pgtable-h/20250818-101531
base: tip/master
patch link: https://lore.kernel.org/r/20250818020206.4517-3-harry.yoo%40oracle.com
patch subject: [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
config: arm64-randconfig-001-20250818 (https://download.01.org/0day-ci/archive/20250818/202508181636.0Rtk0T7x-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250818/202508181636.0Rtk0T7x-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508181636.0Rtk0T7x-lkp@intel.com/
All errors (new ones prefixed by >>):
aarch64-linux-ld: mm/kasan/init.o: in function `zero_p4d_populate':
>> mm/kasan/init.c:195:(.ref.text+0x374): undefined reference to `kasan_early_shadow_pud'
>> mm/kasan/init.c:195:(.ref.text+0x374): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_pud'
>> aarch64-linux-ld: mm/kasan/init.c:195:(.ref.text+0x378): undefined reference to `kasan_early_shadow_pud'
aarch64-linux-ld: mm/kasan/init.o: in function `kasan_populate_early_shadow':
mm/kasan/init.c:258:(.ref.text+0x41c): undefined reference to `kasan_early_shadow_pud'
mm/kasan/init.c:258:(.ref.text+0x41c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_pud'
aarch64-linux-ld: mm/kasan/init.c:258:(.ref.text+0x420): undefined reference to `kasan_early_shadow_pud'
>> aarch64-linux-ld: mm/kasan/init.c:255:(.ref.text+0x42c): undefined reference to `kasan_early_shadow_p4d'
>> mm/kasan/init.c:255:(.ref.text+0x42c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_p4d'
aarch64-linux-ld: mm/kasan/init.c:255:(.ref.text+0x430): undefined reference to `kasan_early_shadow_p4d'
vim +195 mm/kasan/init.c
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 181
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 182 static int __ref zero_p4d_populate(pgd_t *pgd, unsigned long addr,
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 183 unsigned long end)
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 184 {
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 185 p4d_t *p4d = p4d_offset(pgd, addr);
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 186 unsigned long next;
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 187
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 188 do {
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 189 next = p4d_addr_end(addr, end);
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 190 if (IS_ALIGNED(addr, P4D_SIZE) && end - addr >= P4D_SIZE) {
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 191 pud_t *pud;
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 192 pmd_t *pmd;
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 193
a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 194 p4d_populate_kernel(addr, p4d,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 @195 lm_alias(kasan_early_shadow_pud));
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 196 pud = pud_offset(p4d, addr);
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 197 pud_populate(&init_mm, pud,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 198 lm_alias(kasan_early_shadow_pmd));
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 199 pmd = pmd_offset(pud, addr);
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 200 pmd_populate_kernel(&init_mm, pmd,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 201 lm_alias(kasan_early_shadow_pte));
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 202 continue;
458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 203 }
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 204
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 205 if (p4d_none(*p4d)) {
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 206 pud_t *p;
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 207
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 208 if (slab_is_available()) {
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 209 p = pud_alloc(&init_mm, p4d, addr);
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 210 if (!p)
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 211 return -ENOMEM;
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 212 } else {
fb6d5c1d99ab69 mm/kasan/init.c Qing Zhang 2023-09-06 213 p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
fb6d5c1d99ab69 mm/kasan/init.c Qing Zhang 2023-09-06 214 pud_init(p);
a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 215 p4d_populate_kernel(addr, p4d, p);
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 216 }
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 217 }
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 218 zero_pud_populate(p4d, addr, next);
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 219 } while (p4d++, addr = next, addr != end);
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 220
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 221 return 0;
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 222 }
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 223
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 224 /**
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 225 * kasan_populate_early_shadow - populate shadow memory region with
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 226 * kasan_early_shadow_page
7b6889f54a3c8c mm/kasan/init.c Yu Kuai 2021-06-04 227 * @shadow_start: start of the memory range to populate
7b6889f54a3c8c mm/kasan/init.c Yu Kuai 2021-06-04 228 * @shadow_end: end of the memory range to populate
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 229 */
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 230 int __ref kasan_populate_early_shadow(const void *shadow_start,
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 231 const void *shadow_end)
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 232 {
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 233 unsigned long addr = (unsigned long)shadow_start;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 234 unsigned long end = (unsigned long)shadow_end;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 235 pgd_t *pgd = pgd_offset_k(addr);
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 236 unsigned long next;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 237
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 238 do {
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 239 next = pgd_addr_end(addr, end);
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 240
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 241 if (IS_ALIGNED(addr, PGDIR_SIZE) && end - addr >= PGDIR_SIZE) {
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 242 p4d_t *p4d;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 243 pud_t *pud;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 244 pmd_t *pmd;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 245
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 246 /*
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 247 * kasan_early_shadow_pud should be populated with pmds
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 248 * at this moment.
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 249 * [pud,pmd]_populate*() below needed only for
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 250 * 3,2 - level page tables where we don't have
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 251 * puds,pmds, so pgd_populate(), pud_populate()
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 252 * is noops.
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 253 */
a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 254 pgd_populate_kernel(addr, pgd,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 @255 lm_alias(kasan_early_shadow_p4d));
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 256 p4d = p4d_offset(pgd, addr);
a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 257 p4d_populate_kernel(addr, p4d,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 258 lm_alias(kasan_early_shadow_pud));
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 259 pud = pud_offset(p4d, addr);
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 260 pud_populate(&init_mm, pud,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 261 lm_alias(kasan_early_shadow_pmd));
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 262 pmd = pmd_offset(pud, addr);
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 263 pmd_populate_kernel(&init_mm, pmd,
9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 264 lm_alias(kasan_early_shadow_pte));
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 265 continue;
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 266 }
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 267
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 268 if (pgd_none(*pgd)) {
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 269 p4d_t *p;
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 270
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 271 if (slab_is_available()) {
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 272 p = p4d_alloc(&init_mm, pgd, addr);
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 273 if (!p)
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 274 return -ENOMEM;
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 275 } else {
a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 276 pgd_populate_kernel(addr, pgd,
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 277 early_alloc(PAGE_SIZE, NUMA_NO_NODE));
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 278 }
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 279 }
c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 280 zero_p4d_populate(pgd, addr, next);
69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 281 } while (pgd++, addr = next, addr != end);
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 282
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 283 return 0;
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 284 }
0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 285
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
2025-08-18 9:02 ` kernel test robot
@ 2025-08-18 10:41 ` Harry Yoo
0 siblings, 0 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-18 10:41 UTC (permalink / raw)
To: kernel test robot; +Cc: oe-kbuild-all
On Mon, Aug 18, 2025 at 05:02:01PM +0800, kernel test robot wrote:
> Hi Harry,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on tip/master]
> [also build test ERROR on linus/master v6.17-rc2 next-20250818]
> [cannot apply to akpm-mm/mm-everything tip/x86/core tip/x86/mm tip/auto-latest dennis-percpu/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
This is based on akpm-mm/mm-hotfixes-unstable:
e4321cf73f53 mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch*_base_tree_information ]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Harry-Yoo/mm-move-page-table-sync-declarations-to-linux-pgtable-h/20250818-101531
> base: tip/master
> patch link: https://lore.kernel.org/r/20250818020206.4517-3-harry.yoo*40oracle.com
> patch subject: [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
> config: arm64-randconfig-001-20250818 (https://download.01.org/0day-ci/archive/20250818/202508181636.0Rtk0T7x-lkp@intel.com/config )
> compiler: aarch64-linux-gcc (GCC) 11.5.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250818/202508181636.0Rtk0T7x-lkp@intel.com/reproduce )
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202508181636.0Rtk0T7x-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> aarch64-linux-ld: mm/kasan/init.o: in function `zero_p4d_populate':
> >> mm/kasan/init.c:195:(.ref.text+0x374): undefined reference to `kasan_early_shadow_pud'
> >> mm/kasan/init.c:195:(.ref.text+0x374): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_pud'
> >> aarch64-linux-ld: mm/kasan/init.c:195:(.ref.text+0x378): undefined reference to `kasan_early_shadow_pud'
> aarch64-linux-ld: mm/kasan/init.o: in function `kasan_populate_early_shadow':
> mm/kasan/init.c:258:(.ref.text+0x41c): undefined reference to `kasan_early_shadow_pud'
> mm/kasan/init.c:258:(.ref.text+0x41c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_pud'
> aarch64-linux-ld: mm/kasan/init.c:258:(.ref.text+0x420): undefined reference to `kasan_early_shadow_pud'
> >> aarch64-linux-ld: mm/kasan/init.c:255:(.ref.text+0x42c): undefined reference to `kasan_early_shadow_p4d'
> >> mm/kasan/init.c:255:(.ref.text+0x42c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `kasan_early_shadow_p4d'
> aarch64-linux-ld: mm/kasan/init.c:255:(.ref.text+0x430): undefined reference to `kasan_early_shadow_p4d'
My patch series shouldn't be causing this.
Does this error trigger before applying my patch series?
--
Cheers,
Harry / Hyeonggon
> vim +195 mm/kasan/init.c
>
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 181
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 182 static int __ref zero_p4d_populate(pgd_t *pgd, unsigned long addr,
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 183 unsigned long end)
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 184 {
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 185 p4d_t *p4d = p4d_offset(pgd, addr);
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 186 unsigned long next;
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 187
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 188 do {
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 189 next = p4d_addr_end(addr, end);
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 190 if (IS_ALIGNED(addr, P4D_SIZE) && end - addr >= P4D_SIZE) {
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 191 pud_t *pud;
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 192 pmd_t *pmd;
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 193
> a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 194 p4d_populate_kernel(addr, p4d,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 @195 lm_alias(kasan_early_shadow_pud));
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 196 pud = pud_offset(p4d, addr);
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 197 pud_populate(&init_mm, pud,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 198 lm_alias(kasan_early_shadow_pmd));
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 199 pmd = pmd_offset(pud, addr);
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 200 pmd_populate_kernel(&init_mm, pmd,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 201 lm_alias(kasan_early_shadow_pte));
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 202 continue;
> 458f7920f9b1e6 mm/kasan/kasan_init.c Joonsoo Kim 2017-07-10 203 }
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 204
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 205 if (p4d_none(*p4d)) {
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 206 pud_t *p;
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 207
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 208 if (slab_is_available()) {
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 209 p = pud_alloc(&init_mm, p4d, addr);
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 210 if (!p)
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 211 return -ENOMEM;
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 212 } else {
> fb6d5c1d99ab69 mm/kasan/init.c Qing Zhang 2023-09-06 213 p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
> fb6d5c1d99ab69 mm/kasan/init.c Qing Zhang 2023-09-06 214 pud_init(p);
> a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 215 p4d_populate_kernel(addr, p4d, p);
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 216 }
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 217 }
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 218 zero_pud_populate(p4d, addr, next);
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 219 } while (p4d++, addr = next, addr != end);
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 220
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 221 return 0;
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 222 }
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 223
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 224 /**
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 225 * kasan_populate_early_shadow - populate shadow memory region with
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 226 * kasan_early_shadow_page
> 7b6889f54a3c8c mm/kasan/init.c Yu Kuai 2021-06-04 227 * @shadow_start: start of the memory range to populate
> 7b6889f54a3c8c mm/kasan/init.c Yu Kuai 2021-06-04 228 * @shadow_end: end of the memory range to populate
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 229 */
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 230 int __ref kasan_populate_early_shadow(const void *shadow_start,
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 231 const void *shadow_end)
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 232 {
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 233 unsigned long addr = (unsigned long)shadow_start;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 234 unsigned long end = (unsigned long)shadow_end;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 235 pgd_t *pgd = pgd_offset_k(addr);
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 236 unsigned long next;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 237
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 238 do {
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 239 next = pgd_addr_end(addr, end);
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 240
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 241 if (IS_ALIGNED(addr, PGDIR_SIZE) && end - addr >= PGDIR_SIZE) {
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 242 p4d_t *p4d;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 243 pud_t *pud;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 244 pmd_t *pmd;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 245
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 246 /*
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 247 * kasan_early_shadow_pud should be populated with pmds
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 248 * at this moment.
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 249 * [pud,pmd]_populate*() below needed only for
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 250 * 3,2 - level page tables where we don't have
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 251 * puds,pmds, so pgd_populate(), pud_populate()
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 252 * is noops.
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 253 */
> a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 254 pgd_populate_kernel(addr, pgd,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 @255 lm_alias(kasan_early_shadow_p4d));
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 256 p4d = p4d_offset(pgd, addr);
> a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 257 p4d_populate_kernel(addr, p4d,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 258 lm_alias(kasan_early_shadow_pud));
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 259 pud = pud_offset(p4d, addr);
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 260 pud_populate(&init_mm, pud,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 261 lm_alias(kasan_early_shadow_pmd));
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 262 pmd = pmd_offset(pud, addr);
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 263 pmd_populate_kernel(&init_mm, pmd,
> 9577dd74864877 mm/kasan/init.c Andrey Konovalov 2018-12-28 264 lm_alias(kasan_early_shadow_pte));
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 265 continue;
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 266 }
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 267
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 268 if (pgd_none(*pgd)) {
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 269 p4d_t *p;
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 270
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 271 if (slab_is_available()) {
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 272 p = p4d_alloc(&init_mm, pgd, addr);
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 273 if (!p)
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 274 return -ENOMEM;
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 275 } else {
> a86b0f4e94542c mm/kasan/init.c Harry Yoo 2025-08-18 276 pgd_populate_kernel(addr, pgd,
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 277 early_alloc(PAGE_SIZE, NUMA_NO_NODE));
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 278 }
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 279 }
> c2febafc67734a mm/kasan/kasan_init.c Kirill A. Shutemov 2017-03-09 280 zero_p4d_populate(pgd, addr, next);
> 69786cdb379bbc mm/kasan/kasan_init.c Andrey Ryabinin 2015-08-13 281 } while (pgd++, addr = next, addr != end);
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 282
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 283 return 0;
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 284 }
> 0207df4fa1a869 mm/kasan/kasan_init.c Andrey Ryabinin 2018-08-17 285
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
2025-08-18 7:48 ` David Hildenbrand
2025-08-18 9:02 ` kernel test robot
@ 2025-08-21 9:35 ` Harry Yoo
2025-08-21 9:38 ` kernel test robot
` (2 more replies)
2025-08-22 2:07 ` [PATCH v3] " Harry Yoo
3 siblings, 3 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-21 9:35 UTC (permalink / raw)
To: harry.yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch
KASAN unconditionally references kasan_early_shadow_{p4d,pud}.
However, these global variables may not exist depending on the number of
page table levels. For example, if CONFIG_PGTABLE_LEVELS=3, both
variables do not exist. Although KASAN may refernce non-existent
variables, it didn't break builds because calls to {pgd,p4d}_populate()
are optimized away at compile time.
However, {pgd,p4d}_populate_kernel() is defined as a function regardless
of the number of page table levels, so the compiler may not optimize
them away. In this case, the following linker error occurs:
ld.lld: error: undefined symbol: kasan_early_shadow_p4d
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> did you mean: kasan_early_shadow_pmd
>>> defined in: vmlinux.a(mm/kasan/init.o)
ld.lld: error: undefined symbol: kasan_early_shadow_pud
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:200 (/home/hyeyoo/mm-new/mm/kasan/init.c:200)
>>> mm/kasan/init.o:(zero_p4d_populate) in archive vmlinux.a
>>> referenced 1 more times
Therefore, to allow calls to {pgd,p4d}_populate_kernel() to be optimized
out at compile time, define {pgd,p4d}_populate_kernel() as macros.
This way, when pgd_populate() or p4d_populate() are simply empty macros,
the corresponding *_populate_kernel() functions can also be optimized
away.
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
While the description is quite verbose, it is intended to be fold-merged
into patch [1] of the page table sync series V5.
[1] https://lore.kernel.org/linux-mm/20250818020206.4517-3-harry.yoo@oracle.com/
include/linux/pgalloc.h | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/include/linux/pgalloc.h b/include/linux/pgalloc.h
index 290ab864320f..8812f842978f 100644
--- a/include/linux/pgalloc.h
+++ b/include/linux/pgalloc.h
@@ -5,20 +5,18 @@
#include <linux/pgtable.h>
#include <asm/pgalloc.h>
-static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
- p4d_t *p4d)
-{
- pgd_populate(&init_mm, pgd, p4d);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+#define pgd_populate_kernel(addr, pgd, p4d) \
+ do { \
+ pgd_populate(&init_mm, pgd, p4d); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
-static inline void p4d_populate_kernel(unsigned long addr, p4d_t *p4d,
- pud_t *pud)
-{
- p4d_populate(&init_mm, p4d, pud);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+#define p4d_populate_kernel(addr, p4d, pud) \
+ do { \
+ p4d_populate(&init_mm, p4d, pud); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
#endif /* _LINUX_PGALLOC_H */
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 9:35 ` [PATCH] mm: fix KASAN build error due to p*d_populate_kernel() Harry Yoo
@ 2025-08-21 9:38 ` kernel test robot
2025-08-21 10:10 ` Lorenzo Stoakes
2025-08-21 11:57 ` [PATCH v2] " Harry Yoo
2 siblings, 0 replies; 24+ messages in thread
From: kernel test robot @ 2025-08-21 9:38 UTC (permalink / raw)
To: Harry Yoo; +Cc: stable, oe-kbuild-all
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
Link: https://lore.kernel.org/stable/20250821093542.37844-1-harry.yoo%40oracle.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 9:35 ` [PATCH] mm: fix KASAN build error due to p*d_populate_kernel() Harry Yoo
2025-08-21 9:38 ` kernel test robot
@ 2025-08-21 10:10 ` Lorenzo Stoakes
2025-08-21 10:42 ` Harry Yoo
2025-08-21 11:57 ` [PATCH v2] " Harry Yoo
2 siblings, 1 reply; 24+ messages in thread
From: Lorenzo Stoakes @ 2025-08-21 10:10 UTC (permalink / raw)
To: Harry Yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, luto, maobibo, mhocko, mingo, osalvador,
peterx, peterz, rppt, ryabinin.a.a, ryan.roberts, stable, surenb,
tglx, thuth, tj, urezki, vbabka, vincenzo.frascino, x86,
zhengqi.arch
On Thu, Aug 21, 2025 at 06:35:42PM +0900, Harry Yoo wrote:
> KASAN unconditionally references kasan_early_shadow_{p4d,pud}.
> However, these global variables may not exist depending on the number of
> page table levels. For example, if CONFIG_PGTABLE_LEVELS=3, both
> variables do not exist. Although KASAN may refernce non-existent
> variables, it didn't break builds because calls to {pgd,p4d}_populate()
> are optimized away at compile time.
>
> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
> of the number of page table levels, so the compiler may not optimize
> them away. In this case, the following linker error occurs:
>
> ld.lld: error: undefined symbol: kasan_early_shadow_p4d
> >>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
> >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> >>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
> >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> >>> did you mean: kasan_early_shadow_pmd
> >>> defined in: vmlinux.a(mm/kasan/init.o)
>
> ld.lld: error: undefined symbol: kasan_early_shadow_pud
> >>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
> >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> >>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
> >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> >>> referenced by init.c:200 (/home/hyeyoo/mm-new/mm/kasan/init.c:200)
> >>> mm/kasan/init.o:(zero_p4d_populate) in archive vmlinux.a
> >>> referenced 1 more times
>
> Therefore, to allow calls to {pgd,p4d}_populate_kernel() to be optimized
> out at compile time, define {pgd,p4d}_populate_kernel() as macros.
> This way, when pgd_populate() or p4d_populate() are simply empty macros,
> the corresponding *_populate_kernel() functions can also be optimized
> away.
>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
This looks good, other than the nit below re: a comment, I think when we
are doing this kind of thing it's necessary to spell out plainly why
exactly we're doing it because it's not obvious at first glance.
Anyway have checked locally and all good and LGTM code-wise so aside from
above:
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
>
> While the description is quite verbose, it is intended to be fold-merged
> into patch [1] of the page table sync series V5.
>
> [1] https://lore.kernel.org/linux-mm/20250818020206.4517-3-harry.yoo@oracle.com/
>
> include/linux/pgalloc.h | 26 ++++++++++++--------------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/pgalloc.h b/include/linux/pgalloc.h
> index 290ab864320f..8812f842978f 100644
> --- a/include/linux/pgalloc.h
> +++ b/include/linux/pgalloc.h
> @@ -5,20 +5,18 @@
> #include <linux/pgtable.h>
> #include <asm/pgalloc.h>
>
> -static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
> - p4d_t *p4d)
> -{
> - pgd_populate(&init_mm, pgd, p4d);
> - if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED)
> - arch_sync_kernel_mappings(addr, addr);
> -}
> +#define pgd_populate_kernel(addr, pgd, p4d) \
> + do { \
> + pgd_populate(&init_mm, pgd, p4d); \
> + if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) \
> + arch_sync_kernel_mappings(addr, addr); \
> + } while (0)
>
> -static inline void p4d_populate_kernel(unsigned long addr, p4d_t *p4d,
> - pud_t *pud)
> -{
> - p4d_populate(&init_mm, p4d, pud);
> - if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED)
> - arch_sync_kernel_mappings(addr, addr);
> -}
> +#define p4d_populate_kernel(addr, p4d, pud) \
> + do { \
> + p4d_populate(&init_mm, p4d, pud); \
> + if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED) \
> + arch_sync_kernel_mappings(addr, addr); \
> + } while (0)
>
Can we have a quick comment above these explaining why they have to be
macros? Thanks!
> #endif /* _LINUX_PGALLOC_H */
> --
> 2.43.0
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 10:10 ` Lorenzo Stoakes
@ 2025-08-21 10:42 ` Harry Yoo
2025-08-21 11:46 ` Lorenzo Stoakes
0 siblings, 1 reply; 24+ messages in thread
From: Harry Yoo @ 2025-08-21 10:42 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, luto, maobibo, mhocko, mingo, osalvador,
peterx, peterz, rppt, ryabinin.a.a, ryan.roberts, stable, surenb,
tglx, thuth, tj, urezki, vbabka, vincenzo.frascino, x86,
zhengqi.arch
On Thu, Aug 21, 2025 at 11:10:39AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 21, 2025 at 06:35:42PM +0900, Harry Yoo wrote:
> > KASAN unconditionally references kasan_early_shadow_{p4d,pud}.
> > However, these global variables may not exist depending on the number of
> > page table levels. For example, if CONFIG_PGTABLE_LEVELS=3, both
> > variables do not exist. Although KASAN may refernce non-existent
> > variables, it didn't break builds because calls to {pgd,p4d}_populate()
> > are optimized away at compile time.
> >
> > However, {pgd,p4d}_populate_kernel() is defined as a function regardless
> > of the number of page table levels, so the compiler may not optimize
> > them away. In this case, the following linker error occurs:
> >
> > ld.lld: error: undefined symbol: kasan_early_shadow_p4d
> > >>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
> > >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> > >>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
> > >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> > >>> did you mean: kasan_early_shadow_pmd
> > >>> defined in: vmlinux.a(mm/kasan/init.o)
> >
> > ld.lld: error: undefined symbol: kasan_early_shadow_pud
> > >>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
> > >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> > >>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
> > >>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
> > >>> referenced by init.c:200 (/home/hyeyoo/mm-new/mm/kasan/init.c:200)
> > >>> mm/kasan/init.o:(zero_p4d_populate) in archive vmlinux.a
> > >>> referenced 1 more times
> >
> > Therefore, to allow calls to {pgd,p4d}_populate_kernel() to be optimized
> > out at compile time, define {pgd,p4d}_populate_kernel() as macros.
> > This way, when pgd_populate() or p4d_populate() are simply empty macros,
> > the corresponding *_populate_kernel() functions can also be optimized
> > away.
> >
> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
>
> This looks good, other than the nit below re: a comment, I think when we
> are doing this kind of thing it's necessary to spell out plainly why
> exactly we're doing it because it's not obvious at first glance.
Good point, will do:
/*
* {pgd,p4d}_populate_kernel() are defined as macros to allow
* compile-time optimization based on the configured page table levels.
* Without this, linking may fail because callers (e.g., KASAN) may rely
* on calls to these functions being optimized away when passing symbols
* that exist only for certain page table levels.
*/
> Anyway have checked locally and all good and LGTM code-wise so aside from
> above:
>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Thanks!
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 10:42 ` Harry Yoo
@ 2025-08-21 11:46 ` Lorenzo Stoakes
0 siblings, 0 replies; 24+ messages in thread
From: Lorenzo Stoakes @ 2025-08-21 11:46 UTC (permalink / raw)
To: Harry Yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, luto, maobibo, mhocko, mingo, osalvador,
peterx, peterz, rppt, ryabinin.a.a, ryan.roberts, stable, surenb,
tglx, thuth, tj, urezki, vbabka, vincenzo.frascino, x86,
zhengqi.arch
On Thu, Aug 21, 2025 at 07:42:06PM +0900, Harry Yoo wrote:
> > > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> >
> > This looks good, other than the nit below re: a comment, I think when we
> > are doing this kind of thing it's necessary to spell out plainly why
> > exactly we're doing it because it's not obvious at first glance.
>
> Good point, will do:
>
> /*
> * {pgd,p4d}_populate_kernel() are defined as macros to allow
> * compile-time optimization based on the configured page table levels.
> * Without this, linking may fail because callers (e.g., KASAN) may rely
> * on calls to these functions being optimized away when passing symbols
> * that exist only for certain page table levels.
> */
Thanks LGTM!
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 9:35 ` [PATCH] mm: fix KASAN build error due to p*d_populate_kernel() Harry Yoo
2025-08-21 9:38 ` kernel test robot
2025-08-21 10:10 ` Lorenzo Stoakes
@ 2025-08-21 11:57 ` Harry Yoo
2025-08-21 12:00 ` kernel test robot
2025-08-21 17:36 ` Dave Hansen
2 siblings, 2 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-21 11:57 UTC (permalink / raw)
To: harry.yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch
KASAN unconditionally references kasan_early_shadow_{p4d,pud}.
However, these global variables may not exist depending on the number of
page table levels. For example, if CONFIG_PGTABLE_LEVELS=3, both
variables do not exist. Although KASAN may refernce non-existent
variables, it didn't break builds because calls to {pgd,p4d}_populate()
are optimized away at compile time.
However, {pgd,p4d}_populate_kernel() is defined as a function regardless
of the number of page table levels, so the compiler may not optimize
them away. In this case, the following linker error occurs:
ld.lld: error: undefined symbol: kasan_early_shadow_p4d
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> did you mean: kasan_early_shadow_pmd
>>> defined in: vmlinux.a(mm/kasan/init.o)
ld.lld: error: undefined symbol: kasan_early_shadow_pud
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:200 (/home/hyeyoo/mm-new/mm/kasan/init.c:200)
>>> mm/kasan/init.o:(zero_p4d_populate) in archive vmlinux.a
>>> referenced 1 more times
Therefore, to allow calls to {pgd,p4d}_populate_kernel() to be optimized
out at compile time, define {pgd,p4d}_populate_kernel() as macros.
This way, when pgd_populate() or p4d_populate() are simply empty macros,
the corresponding *_populate_kernel() functions can also be optimized
away.
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
v1 -> v2: added comment per Lorenzo's comment.
include/linux/pgalloc.h | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/pgalloc.h b/include/linux/pgalloc.h
index 290ab864320f..9174fa59bbc5 100644
--- a/include/linux/pgalloc.h
+++ b/include/linux/pgalloc.h
@@ -5,20 +5,25 @@
#include <linux/pgtable.h>
#include <asm/pgalloc.h>
-static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
- p4d_t *p4d)
-{
- pgd_populate(&init_mm, pgd, p4d);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+/*
+ * {pgd,p4d}_populate_kernel() are defined as macros to allow
+ * compile-time optimization based on the configured page table levels.
+ * Without this, linking may fail because callers (e.g., KASAN) may rely
+ * on calls to these functions being optimized away when passing symbols
+ * that exist only for certain page table levels.
+ */
+#define pgd_populate_kernel(addr, pgd, p4d) \
+ do { \
+ pgd_populate(&init_mm, pgd, p4d); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
-static inline void p4d_populate_kernel(unsigned long addr, p4d_t *p4d,
- pud_t *pud)
-{
- p4d_populate(&init_mm, p4d, pud);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+#define p4d_populate_kernel(addr, p4d, pud) \
+ do { \
+ p4d_populate(&init_mm, p4d, pud); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
#endif /* _LINUX_PGALLOC_H */
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 11:57 ` [PATCH v2] " Harry Yoo
@ 2025-08-21 12:00 ` kernel test robot
2025-08-21 17:36 ` Dave Hansen
1 sibling, 0 replies; 24+ messages in thread
From: kernel test robot @ 2025-08-21 12:00 UTC (permalink / raw)
To: Harry Yoo; +Cc: stable, oe-kbuild-all
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
Link: https://lore.kernel.org/stable/20250821115731.137284-1-harry.yoo%40oracle.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 11:57 ` [PATCH v2] " Harry Yoo
2025-08-21 12:00 ` kernel test robot
@ 2025-08-21 17:36 ` Dave Hansen
2025-08-22 1:11 ` Harry Yoo
1 sibling, 1 reply; 24+ messages in thread
From: Dave Hansen @ 2025-08-21 17:36 UTC (permalink / raw)
To: Harry Yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch
On 8/21/25 04:57, Harry Yoo wrote:
> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
> of the number of page table levels, so the compiler may not optimize
> them away. In this case, the following linker error occurs:
This part of the changelog confused me. I think it's focusing on the
wrong thing.
The code that's triggering this is literally:
> pgd_populate(&init_mm, pgd,
> lm_alias(kasan_early_shadow_p4d));
It sure _looks_ like it's unconditionally referencing the
'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
macro magic and just assume that the macros won't reference it.
If a symbol isn't being defined, it shouldn't be referenced in C code.:q
The right way to do it is to have an #ifdef in a header that avoids
compiling in the reference to the symbol.
But just changing the 'static inline' to a #define seems like a fragile
hack to me.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-21 17:36 ` Dave Hansen
@ 2025-08-22 1:11 ` Harry Yoo
2025-08-22 16:02 ` Andrey Ryabinin
2025-08-22 17:08 ` Dave Hansen
0 siblings, 2 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-22 1:11 UTC (permalink / raw)
To: Dave Hansen
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch
On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
> On 8/21/25 04:57, Harry Yoo wrote:
> > However, {pgd,p4d}_populate_kernel() is defined as a function regardless
> > of the number of page table levels, so the compiler may not optimize
> > them away. In this case, the following linker error occurs:
Hi, thanks for taking a look, Dave!
First of all, this is a fix-up patch of a mm-hotfixes patch series that
fixes a bug (I should have explained that in the changelog) [1].
[1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
I think we can continue discussing it and perhaps do that as part of
a follow-up series, because the current patch series need to be backported
to -stable and your suggestion to improve existing code doesn't require
-stable backports.
Does that sound fine?
> This part of the changelog confused me. I think it's focusing on the
> wrong thing.
>
> The code that's triggering this is literally:
>
> > pgd_populate(&init_mm, pgd,
> > lm_alias(kasan_early_shadow_p4d));
>
> It sure _looks_ like it's unconditionally referencing the
> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
> macro magic and just assume that the macros won't reference it.
>
> If a symbol isn't being defined, it shouldn't be referenced in C code.:q
A fair point, and that's what KASAN code has been doing for years.
> The right way to do it is to have an #ifdef in a header that avoids
> compiling in the reference to the symbol.
You mean defining some wrapper functions for p*d_populate_kernel() in
KASAN with different implementations based on ifdeffery?
Just to clarify, what should be the exact ifdeffery to cover these cases?
#if CONFIG_PGTABLE_LEVELS == 4 and 5, or
#ifdef __PAGETABLE_P4D_FOLDED and __PAGETABLE_PUD_FOLDED ?
I have no strong opinion on this, let's hear what KASAN folks think.
> But just changing the 'static inline' to a #define seems like a fragile
> hack to me.
At least that's what KASAN has relied on p*d_populate() to do...
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-22 1:11 ` Harry Yoo
@ 2025-08-22 16:02 ` Andrey Ryabinin
2025-08-27 6:30 ` Harry Yoo
2025-08-22 17:08 ` Dave Hansen
1 sibling, 1 reply; 24+ messages in thread
From: Andrey Ryabinin @ 2025-08-22 16:02 UTC (permalink / raw)
To: Harry Yoo, Dave Hansen
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryan.roberts, stable,
surenb, tglx, thuth, tj, urezki, vbabka, vincenzo.frascino, x86,
zhengqi.arch
On 8/22/25 3:11 AM, Harry Yoo wrote:
> On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
>> On 8/21/25 04:57, Harry Yoo wrote:
>>> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
>>> of the number of page table levels, so the compiler may not optimize
>>> them away. In this case, the following linker error occurs:
>
> Hi, thanks for taking a look, Dave!
>
> First of all, this is a fix-up patch of a mm-hotfixes patch series that
> fixes a bug (I should have explained that in the changelog) [1].
>
> [1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
>
> I think we can continue discussing it and perhaps do that as part of
> a follow-up series, because the current patch series need to be backported
> to -stable and your suggestion to improve existing code doesn't require
> -stable backports.
>
> Does that sound fine?
>
>> This part of the changelog confused me. I think it's focusing on the
>> wrong thing.
>>
>> The code that's triggering this is literally:
>>
>>> pgd_populate(&init_mm, pgd,
>>> lm_alias(kasan_early_shadow_p4d));
>>
>> It sure _looks_ like it's unconditionally referencing the
>> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
>> macro magic and just assume that the macros won't reference it.
>>
>> If a symbol isn't being defined, it shouldn't be referenced in C code.:q
That's not exactly the case for the kernel. It historically relied on being
compiled with optimization and compiler being able to eliminate unused references.
AFAIR BUILD_BUG_ON() works like that, there are also plenty of code like
if (IS_ENABLED(CONFIG_SOMETHING))
ptr = &something;
else
ptr = &something_else;
e.g. irq_remaping_prepare();
>
> A fair point, and that's what KASAN code has been doing for years.
>
>> The right way to do it is to have an #ifdef in a header that avoids
>> compiling in the reference to the symbol.
>
> You mean defining some wrapper functions for p*d_populate_kernel() in
> KASAN with different implementations based on ifdeffery?
>
> Just to clarify, what should be the exact ifdeffery to cover these cases?
> #if CONFIG_PGTABLE_LEVELS == 4 and 5, or
> #ifdef __PAGETABLE_P4D_FOLDED and __PAGETABLE_PUD_FOLDED ?
>
I think ifdef should be the same as for symbol, so '#if CONFIG_PGTABLE_LEVELS > 4'
for *_p4d and '#if CONFIG_PGTABLE_LEVELS > 3' for *_pud
> I have no strong opinion on this, let's hear what KASAN folks think.
>
So, I think we have following options:
1. Macros as you did.
2. Hide references in function under '#if CONFIG_PGTABLE_LEVELS > x', like Dave suggested.
3. It should be enough to just add if in code like
if (CONFIG_PGTABLE_LEVELS > 4)
pgd_populate_kernel(addr, pgd,
lm_alias(kasan_early_shadow_p4d));
Compiler should be able to optimize it away.
4. I guess that the link error is due to enabled CONFIG_DEBUG_VIRTUAL=y
lm_alias() ends up with __phys_addr_symbol() function call which compiler can't optimize away.
Technically we can declare __phys_addr_symbol() with __attribute__((pure)), so compiler will
be able to optimize away this call, because the result should be unused.
But I'm not sure we really want that, because it's debug function and even if the result is unused
we might want to still have a check if symbol address is correct.
I would probably prefer 3rd option, but I don't really have very strong opinion, so either way is fine.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-22 16:02 ` Andrey Ryabinin
@ 2025-08-27 6:30 ` Harry Yoo
0 siblings, 0 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-27 6:30 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Dave Hansen, Liam.Howlett, akpm, andreyknvl, aneesh.kumar,
anshuman.khandual, apopple, ardb, arnd, bp, cl, dave.hansen,
david, dennis, dev.jain, dvyukov, glider, gwan-gyeong.mun, hpa,
jane.chu, jgross, jhubbard, joao.m.martins, joro, kas,
kevin.brodsky, linux-arch, linux-kernel, linux-mm,
lorenzo.stoakes, luto, maobibo, mhocko, mingo, osalvador, peterx,
peterz, rppt, ryan.roberts, stable, surenb, tglx, thuth, tj,
urezki, vbabka, vincenzo.frascino, x86, zhengqi.arch
On Fri, Aug 22, 2025 at 06:02:40PM +0200, Andrey Ryabinin wrote:
> On 8/22/25 3:11 AM, Harry Yoo wrote:
> > On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
> >> On 8/21/25 04:57, Harry Yoo wrote:
> >>> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
> >>> of the number of page table levels, so the compiler may not optimize
> >>> them away. In this case, the following linker error occurs:
> >
> > Hi, thanks for taking a look, Dave!
> >
> > First of all, this is a fix-up patch of a mm-hotfixes patch series that
> > fixes a bug (I should have explained that in the changelog) [1].
> >
> > [1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
> >
> > I think we can continue discussing it and perhaps do that as part of
> > a follow-up series, because the current patch series need to be backported
> > to -stable and your suggestion to improve existing code doesn't require
> > -stable backports.
> >
> > Does that sound fine?
> >
> >> This part of the changelog confused me. I think it's focusing on the
> >> wrong thing.
> >>
> >> The code that's triggering this is literally:
> >>
> >>> pgd_populate(&init_mm, pgd,
> >>> lm_alias(kasan_early_shadow_p4d));
> >>
> >> It sure _looks_ like it's unconditionally referencing the
> >> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
> >> macro magic and just assume that the macros won't reference it.
> >>
> >> If a symbol isn't being defined, it shouldn't be referenced in C code.:q
>
> That's not exactly the case for the kernel. It historically relied on being
> compiled with optimization and compiler being able to eliminate unused references.
> AFAIR BUILD_BUG_ON() works like that, there are also plenty of code like
>
> if (IS_ENABLED(CONFIG_SOMETHING))
> ptr = &something;
> else
> ptr = &something_else;
>
> e.g. irq_remaping_prepare();
Agreed. I've seen this pattern in many places.
> > A fair point, and that's what KASAN code has been doing for years.
> >
> >> The right way to do it is to have an #ifdef in a header that avoids
> >> compiling in the reference to the symbol.
> >
> > You mean defining some wrapper functions for p*d_populate_kernel() in
> > KASAN with different implementations based on ifdeffery?
> >
> > Just to clarify, what should be the exact ifdeffery to cover these cases?
> > #if CONFIG_PGTABLE_LEVELS == 4 and 5, or
> > #ifdef __PAGETABLE_P4D_FOLDED and __PAGETABLE_PUD_FOLDED ?
> >
>
> I think ifdef should be the same as for symbol, so '#if CONFIG_PGTABLE_LEVELS > 4'
> for *_p4d and '#if CONFIG_PGTABLE_LEVELS > 3' for *_pud
Right.
> > I have no strong opinion on this, let's hear what KASAN folks think.
> >
>
> So, I think we have following options:
>
> 1. Macros as you did.
> 2. Hide references in function under '#if CONFIG_PGTABLE_LEVELS > x', like Dave suggested.
> 3. It should be enough to just add if in code like
> if (CONFIG_PGTABLE_LEVELS > 4)
> pgd_populate_kernel(addr, pgd,
> lm_alias(kasan_early_shadow_p4d));
> Compiler should be able to optimize it away.
>
> 4. I guess that the link error is due to enabled CONFIG_DEBUG_VIRTUAL=y
> lm_alias() ends up with __phys_addr_symbol() function call which compiler can't optimize away.
> Technically we can declare __phys_addr_symbol() with __attribute__((pure)), so compiler will
> be able to optimize away this call, because the result should be unused.
> But I'm not sure we really want that, because it's debug function and even if the result is unused
> we might want to still have a check if symbol address is correct.
>
>
> I would probably prefer 3rd option, but I don't really have very strong opinion, so either way is fine.
I also prefer 3rd option (but 1st or 2nd is also fine to me)
That's two votes, I'll do 2nd option in the follow-up series unless
Dave or somebody else objects?
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-22 1:11 ` Harry Yoo
2025-08-22 16:02 ` Andrey Ryabinin
@ 2025-08-22 17:08 ` Dave Hansen
2025-08-25 9:46 ` Andrey Ryabinin
1 sibling, 1 reply; 24+ messages in thread
From: Dave Hansen @ 2025-08-22 17:08 UTC (permalink / raw)
To: Harry Yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch
On 8/21/25 18:11, Harry Yoo wrote:
> On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
>> On 8/21/25 04:57, Harry Yoo wrote:
>>> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
>>> of the number of page table levels, so the compiler may not optimize
>>> them away. In this case, the following linker error occurs:
>
> Hi, thanks for taking a look, Dave!
>
> First of all, this is a fix-up patch of a mm-hotfixes patch series that
> fixes a bug (I should have explained that in the changelog) [1].
>
> [1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
>
> I think we can continue discussing it and perhaps do that as part of
> a follow-up series, because the current patch series need to be backported
> to -stable and your suggestion to improve existing code doesn't require
> -stable backports.
>
> Does that sound fine?
>
>> This part of the changelog confused me. I think it's focusing on the
>> wrong thing.
>>
>> The code that's triggering this is literally:
>>
>>> pgd_populate(&init_mm, pgd,
>>> lm_alias(kasan_early_shadow_p4d));
>>
>> It sure _looks_ like it's unconditionally referencing the
>> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
>> macro magic and just assume that the macros won't reference it.
>>
>> If a symbol isn't being defined, it shouldn't be referenced in C code.:q
>
> A fair point, and that's what KASAN code has been doing for years.
>
>> The right way to do it is to have an #ifdef in a header that avoids
>> compiling in the reference to the symbol.
>
> You mean defining some wrapper functions for p*d_populate_kernel() in
> KASAN with different implementations based on ifdeffery?
That would work.
So would something like:
#if CONFIG_PGTABLE_LEVELS >= 4
extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
#else
#define kasan_early_shadow_p4d NULL
#endif
> Just to clarify, what should be the exact ifdeffery to cover these cases?
> #if CONFIG_PGTABLE_LEVELS == 4 and 5, or
> #ifdef __PAGETABLE_P4D_FOLDED and __PAGETABLE_PUD_FOLDED ?
>
> I have no strong opinion on this, let's hear what KASAN folks think.
I think CONFIG_PGTABLE_LEVELS works, but in the end I'm not picky about
the specific #ifdefs that work.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-22 17:08 ` Dave Hansen
@ 2025-08-25 9:46 ` Andrey Ryabinin
0 siblings, 0 replies; 24+ messages in thread
From: Andrey Ryabinin @ 2025-08-25 9:46 UTC (permalink / raw)
To: Dave Hansen, Harry Yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryan.roberts, stable,
surenb, tglx, thuth, tj, urezki, vbabka, vincenzo.frascino, x86,
zhengqi.arch
On 8/22/25 7:08 PM, Dave Hansen wrote:
> On 8/21/25 18:11, Harry Yoo wrote:
>> On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
>>> On 8/21/25 04:57, Harry Yoo wrote:
>>>> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
>>>> of the number of page table levels, so the compiler may not optimize
>>>> them away. In this case, the following linker error occurs:
>>
>> Hi, thanks for taking a look, Dave!
>>
>> First of all, this is a fix-up patch of a mm-hotfixes patch series that
>> fixes a bug (I should have explained that in the changelog) [1].
>>
>> [1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
>>
>> I think we can continue discussing it and perhaps do that as part of
>> a follow-up series, because the current patch series need to be backported
>> to -stable and your suggestion to improve existing code doesn't require
>> -stable backports.
>>
>> Does that sound fine?
>>
>>> This part of the changelog confused me. I think it's focusing on the
>>> wrong thing.
>>>
>>> The code that's triggering this is literally:
>>>
>>>> pgd_populate(&init_mm, pgd,
>>>> lm_alias(kasan_early_shadow_p4d));
>>>
>>> It sure _looks_ like it's unconditionally referencing the
>>> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
>>> macro magic and just assume that the macros won't reference it.
>>>
>>> If a symbol isn't being defined, it shouldn't be referenced in C code.:q
>>
>> A fair point, and that's what KASAN code has been doing for years.
>>
>>> The right way to do it is to have an #ifdef in a header that avoids
>>> compiling in the reference to the symbol.
>>
>> You mean defining some wrapper functions for p*d_populate_kernel() in
>> KASAN with different implementations based on ifdeffery?
>
> That would work.
>
> So would something like:
>
> #if CONFIG_PGTABLE_LEVELS >= 4
> extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
> #else
> #define kasan_early_shadow_p4d NULL
> #endif
>
This won't work. It will fix the linker error, but will introduce runtime bug instead:
lm_alias(kasan_early_shadow_p4d) -> __va(__phys_addr_symbol(NULL))
On arm64:
phys_addr_t __phys_addr_symbol(unsigned long x)
VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START ||
x > (unsigned long) KERNEL_END);
And NULL is < KERNEL_START.
Since __phys_addr_symbol() isn't pure or const, compiler has no right to eliminate such
call even though the return value is unused.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v3] mm: fix KASAN build error due to p*d_populate_kernel()
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
` (2 preceding siblings ...)
2025-08-21 9:35 ` [PATCH] mm: fix KASAN build error due to p*d_populate_kernel() Harry Yoo
@ 2025-08-22 2:07 ` Harry Yoo
3 siblings, 0 replies; 24+ messages in thread
From: Harry Yoo @ 2025-08-22 2:07 UTC (permalink / raw)
To: harry.yoo
Cc: Liam.Howlett, akpm, andreyknvl, aneesh.kumar, anshuman.khandual,
apopple, ardb, arnd, bp, cl, dave.hansen, david, dennis, dev.jain,
dvyukov, glider, gwan-gyeong.mun, hpa, jane.chu, jgross, jhubbard,
joao.m.martins, joro, kas, kevin.brodsky, linux-arch,
linux-kernel, linux-mm, lorenzo.stoakes, luto, maobibo, mhocko,
mingo, osalvador, peterx, peterz, rppt, ryabinin.a.a,
ryan.roberts, stable, surenb, tglx, thuth, tj, urezki, vbabka,
vincenzo.frascino, x86, zhengqi.arch, kernel test robot,
Stephen Rothwell
Address a linker error introduced by a patch currently in mm-hotfixes:
"mm: introduce and use {pgd,p4d}_populate_kernel" [1].
KASAN unconditionally references kasan_early_shadow_{p4d,pud}.
However, these global variables may not exist depending on the number of
page table levels. For example, if CONFIG_PGTABLE_LEVELS=3, both
variables do not exist. Although KASAN may refernce non-existent
variables, it didn't break builds because calls to {pgd,p4d}_populate()
are optimized away at compile time.
However, {pgd,p4d}_populate_kernel() is defined as a function regardless
of the number of page table levels, so the compiler may not optimize
them away. In this case, the following linker error occurs:
ld.lld: error: undefined symbol: kasan_early_shadow_p4d
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:260 (/home/hyeyoo/mm-new/mm/kasan/init.c:260)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> did you mean: kasan_early_shadow_pmd
>>> defined in: vmlinux.a(mm/kasan/init.o)
ld.lld: error: undefined symbol: kasan_early_shadow_pud
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:263 (/home/hyeyoo/mm-new/mm/kasan/init.c:263)
>>> mm/kasan/init.o:(kasan_populate_early_shadow) in archive vmlinux.a
>>> referenced by init.c:200 (/home/hyeyoo/mm-new/mm/kasan/init.c:200)
>>> mm/kasan/init.o:(zero_p4d_populate) in archive vmlinux.a
>>> referenced 1 more times
Therefore, to allow calls to {pgd,p4d}_populate_kernel() to be optimized
out at compile time, define {pgd,p4d}_populate_kernel() as macros.
This way, when pgd_populate() or p4d_populate() are simply empty macros,
the corresponding *_populate_kernel() functions can also be optimized
away.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202508181636.0Rtk0T7x-lkp@intel.com
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/lkml/20250821160515.611d191e@canb.auug.org.au
Link: https://lore.kernel.org/linux-mm/20250818020206.4517-3-harry.yoo@oracle.com [1]
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
This is intended to be fold-merged into the patch
"mm: introduce and use {pgd,p4d}_populate_kernel".
v2 -> v3:
- Explained that this fixes a linker error of a patch in mm-hotfixes.
- Added links to error reports (Closes:) and Reported-by:
include/linux/pgalloc.h | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/pgalloc.h b/include/linux/pgalloc.h
index 290ab864320f..9174fa59bbc5 100644
--- a/include/linux/pgalloc.h
+++ b/include/linux/pgalloc.h
@@ -5,20 +5,25 @@
#include <linux/pgtable.h>
#include <asm/pgalloc.h>
-static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
- p4d_t *p4d)
-{
- pgd_populate(&init_mm, pgd, p4d);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+/*
+ * {pgd,p4d}_populate_kernel() are defined as macros to allow
+ * compile-time optimization based on the configured page table levels.
+ * Without this, linking may fail because callers (e.g., KASAN) may rely
+ * on calls to these functions being optimized away when passing symbols
+ * that exist only for certain page table levels.
+ */
+#define pgd_populate_kernel(addr, pgd, p4d) \
+ do { \
+ pgd_populate(&init_mm, pgd, p4d); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
-static inline void p4d_populate_kernel(unsigned long addr, p4d_t *p4d,
- pud_t *pud)
-{
- p4d_populate(&init_mm, p4d, pud);
- if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED)
- arch_sync_kernel_mappings(addr, addr);
-}
+#define p4d_populate_kernel(addr, p4d, pud) \
+ do { \
+ p4d_populate(&init_mm, p4d, pud); \
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_P4D_MODIFIED) \
+ arch_sync_kernel_mappings(addr, addr); \
+ } while (0)
#endif /* _LINUX_PGALLOC_H */
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()
2025-08-18 2:02 [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss Harry Yoo
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h Harry Yoo
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
@ 2025-08-18 2:02 ` Harry Yoo
2025-08-18 7:49 ` David Hildenbrand
2025-08-18 7:50 ` [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss David Hildenbrand
3 siblings, 1 reply; 24+ messages in thread
From: Harry Yoo @ 2025-08-18 2:02 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andy Lutomirski, Peter Zijlstra, H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, David Hildenbrand,
Gwan-gyeong Mun, Aneesh Kumar K . V, Uladzislau Rezki,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Qi Zheng, Ard Biesheuvel, Thomas Huth, John Hubbard,
Ryan Roberts, Peter Xu, Dev Jain, Bibo Mao, Anshuman Khandual,
Joerg Roedel, x86, linux-kernel, linux-arch, linux-mm, Harry Yoo,
stable, Kiryl Shutsemau
Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure
page tables are properly synchronized when calling
p*d_populate_kernel().
For 5-level paging, synchronization is performed via
pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op,
so synchronization is instead performed at the P4D level via
p4d_populate_kernel().
This fixes intermittent boot failures on systems using 4-level paging
and a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP NOPTI
RIP: 0010:__init_single_page+0x9/0x6d
Call Trace:
<TASK>
__init_zone_device_page+0x17/0x5d
memmap_init_zone_device+0x154/0x1bb
pagemap_range+0x2e0/0x40f
memremap_pages+0x10b/0x2f0
devm_memremap_pages+0x1e/0x60
dev_dax_probe+0xce/0x2ec [device_dax]
dax_bus_probe+0x6d/0xc9
[... snip ...]
</TASK>
It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap
before sync_global_pgds() [1]:
BUG: unable to handle page fault for address: ffffeb3ff1200000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
Tainted: [W]=WARN
RIP: 0010:vmemmap_set_pmd+0xff/0x230
<TASK>
vmemmap_populate_hugepages+0x176/0x180
vmemmap_populate+0x34/0x80
__populate_section_memmap+0x41/0x90
sparse_add_section+0x121/0x3e0
__add_pages+0xba/0x150
add_pages+0x1d/0x70
memremap_pages+0x3dc/0x810
devm_memremap_pages+0x1c/0x60
xe_devm_add+0x8b/0x100 [xe]
xe_tile_init_noalloc+0x6a/0x70 [xe]
xe_device_probe+0x48c/0x740 [xe]
[... snip ...]
Cc: <stable@vger.kernel.org>
Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
Closes: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@intel.com [1]
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Kiryl Shutsemau <kas@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
arch/x86/include/asm/pgtable_64_types.h | 3 +++
arch/x86/mm/init_64.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 4604f924d8b8..7eb61ef6a185 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -36,6 +36,9 @@ static inline bool pgtable_l5_enabled(void)
#define pgtable_l5_enabled() cpu_feature_enabled(X86_FEATURE_LA57)
#endif /* USE_EARLY_PGTABLE_L5 */
+#define ARCH_PAGE_TABLE_SYNC_MASK \
+ (pgtable_l5_enabled() ? PGTBL_PGD_MODIFIED : PGTBL_P4D_MODIFIED)
+
extern unsigned int pgdir_shift;
extern unsigned int ptrs_per_p4d;
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 76e33bd7c556..b9426fce5f3e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -223,6 +223,24 @@ static void sync_global_pgds(unsigned long start, unsigned long end)
sync_global_pgds_l4(start, end);
}
+/*
+ * Make kernel mappings visible in all page tables in the system.
+ * This is necessary except when the init task populates kernel mappings
+ * during the boot process. In that case, all processes originating from
+ * the init task copies the kernel mappings, so there is no issue.
+ * Otherwise, missing synchronization could lead to kernel crashes due
+ * to missing page table entries for certain kernel mappings.
+ *
+ * Synchronization is performed at the top level, which is the PGD in
+ * 5-level paging systems. But in 4-level paging systems, however,
+ * pgd_populate() is a no-op, so synchronization is done at the P4D level.
+ * sync_global_pgds() handles this difference between paging levels.
+ */
+void arch_sync_kernel_mappings(unsigned long start, unsigned long end)
+{
+ sync_global_pgds(start, end);
+}
+
/*
* NOTE: This function is marked __ref because it calls __init function
* (alloc_bootmem_pages). It's safe to do it ONLY when after_bootmem == 0.
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Harry Yoo
@ 2025-08-18 7:49 ` David Hildenbrand
0 siblings, 0 replies; 24+ messages in thread
From: David Hildenbrand @ 2025-08-18 7:49 UTC (permalink / raw)
To: Harry Yoo, Andrew Morton, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, Gwan-gyeong Mun,
Aneesh Kumar K . V, Uladzislau Rezki, Liam R . Howlett,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Qi Zheng,
Ard Biesheuvel, Thomas Huth, John Hubbard, Ryan Roberts, Peter Xu,
Dev Jain, Bibo Mao, Anshuman Khandual, Joerg Roedel, x86,
linux-kernel, linux-arch, linux-mm, stable, Kiryl Shutsemau
On 18.08.25 04:02, Harry Yoo wrote:
> Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure
> page tables are properly synchronized when calling
> p*d_populate_kernel().
>
> For 5-level paging, synchronization is performed via
> pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op,
> so synchronization is instead performed at the P4D level via
> p4d_populate_kernel().
>
> This fixes intermittent boot failures on systems using 4-level paging
> and a large amount of persistent memory:
>
> BUG: unable to handle page fault for address: ffffe70000000034
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP NOPTI
> RIP: 0010:__init_single_page+0x9/0x6d
> Call Trace:
> <TASK>
> __init_zone_device_page+0x17/0x5d
> memmap_init_zone_device+0x154/0x1bb
> pagemap_range+0x2e0/0x40f
> memremap_pages+0x10b/0x2f0
> devm_memremap_pages+0x1e/0x60
> dev_dax_probe+0xce/0x2ec [device_dax]
> dax_bus_probe+0x6d/0xc9
> [... snip ...]
> </TASK>
>
> It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap
> before sync_global_pgds() [1]:
>
> BUG: unable to handle page fault for address: ffffeb3ff1200000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
> Tainted: [W]=WARN
> RIP: 0010:vmemmap_set_pmd+0xff/0x230
> <TASK>
> vmemmap_populate_hugepages+0x176/0x180
> vmemmap_populate+0x34/0x80
> __populate_section_memmap+0x41/0x90
> sparse_add_section+0x121/0x3e0
> __add_pages+0xba/0x150
> add_pages+0x1d/0x70
> memremap_pages+0x3dc/0x810
> devm_memremap_pages+0x1c/0x60
> xe_devm_add+0x8b/0x100 [xe]
> xe_tile_init_noalloc+0x6a/0x70 [xe]
> xe_device_probe+0x48c/0x740 [xe]
> [... snip ...]
>
> Cc: <stable@vger.kernel.org>
> Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
> Closes: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@intel.com [1]
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Acked-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> ---
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss
2025-08-18 2:02 [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss Harry Yoo
` (2 preceding siblings ...)
2025-08-18 2:02 ` [PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Harry Yoo
@ 2025-08-18 7:50 ` David Hildenbrand
3 siblings, 0 replies; 24+ messages in thread
From: David Hildenbrand @ 2025-08-18 7:50 UTC (permalink / raw)
To: Harry Yoo, Andrew Morton, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
H . Peter Anvin
Cc: Andrey Ryabinin, Arnd Bergmann, Dennis Zhou, Tejun Heo,
Christoph Lameter, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Juergen Gross, Kevin Brodsky,
Oscar Salvador, Joao Martins, Lorenzo Sccakes, Jane Chu,
Alistair Popple, Mike Rapoport, Gwan-gyeong Mun,
Aneesh Kumar K . V, Uladzislau Rezki, Liam R . Howlett,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Qi Zheng,
Ard Biesheuvel, Thomas Huth, John Hubbard, Ryan Roberts, Peter Xu,
Dev Jain, Bibo Mao, Anshuman Khandual, Joerg Roedel, x86,
linux-kernel, linux-arch, linux-mm
On 18.08.25 04:02, Harry Yoo wrote:
> To x86 folks:
> It's not clear whether this should go through the MM tree or the x86
> tree as it changes both. We could send it to the MM tree with Acks
> from the x86 folks, or we could send it through the x86 tree instead.
> What do you think?
I think this should go through the MM tree with ACKs on the x86 parts
from respective maintainers.
--
Cheers
David / dhildenb
^ permalink raw reply [flat|nested] 24+ messages in thread