[PATCH v5 0/3] fix wrong usage of memory allocation APIs under PREEMPT_RT in arm64

[PATCH v5 0/3] fix wrong usage of memory allocation APIs under PREEMPT_RT in arm64

[Yeoreum Yun]

Under PREEMPT_RT, calling generic memory allocation/free APIs
(e.x) __get_free_pages(), pgtable_alloc(), free_pages() and etc
with preemption disabled is not allowed, but allow only nolock() APIs series
because it may acquire a spin lock that becomes sleepable on RT,
potentially causing a sleep during page allocation
(See Documentation/core-api/real-time/differences.rst, Memory allocation section).

However, In arm64, __linear_map_split_to_ptes() and
__kpti_install_ng_mappings() called by stopper thread via stop_machine()
use generic memory allocation/free APIs.

This patchset fixes this problem and based on v6.19-rc1

Patch History
==============
from v4 to v5:
  - rebase to v6.19-rc4
  - remove useless __always_inline
  - fix alignments
  - https://lore.kernel.org/all/20260102150736.1378818-1-yeoreum.yun@arm.com/

from v3 to v4:
  - rebase to v6.19-rc3
  - introduce pgtable_alloc_t
  - following several suggestions from @Ryan Roberts
  - https://lore.kernel.org/all/20251218194750.395301-1-yeoreum.yun@arm.com/

from v2 to v3:
  - remove split-mode and split_args.
    pass proper function pointer while spliting.
  - rename function name.
  - https://lore.kernel.org/all/20251217182007.2345700-1-yeoreum.yun@arm.com/

from v1 to v2:
  - drop pagetable_alloc_nolock()
  - following @Ryan Roberts suggestion.
  - https://lore.kernel.org/all/20251212161832.2067134-1-yeoreum.yun@arm.com/

Yeoreum Yun (3):
  arm64: mmu: introduce pgtable_alloc_t
  arm64: mmu: avoid allocating pages while splitting the linear mapping
  arm64: mmu: avoid allocating pages while installing ng-mapping for
    KPTI

 arch/arm64/mm/mmu.c | 241 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 186 insertions(+), 55 deletions(-)

--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v5 1/3] arm64: mmu: introduce pgtable_alloc_t

[Yeoreum Yun]

This is preparation patch to use preallocated page tables
for linear_map_split_to_ptes().

Define pgtable_alloc_t type for callback used by create_XXX_mapping().

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
---
 arch/arm64/mm/mmu.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 8e1d80a7033e..4b4908ae189b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -74,6 +74,8 @@ EXPORT_SYMBOL(empty_zero_page);
 static DEFINE_SPINLOCK(swapper_pgdir_lock);
 static DEFINE_MUTEX(fixmap_lock);
 
+typedef phys_addr_t (pgtable_alloc_t)(enum pgtable_type);
+
 void noinstr set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 {
 	pgd_t *fixmap_pgdp;
@@ -197,7 +199,7 @@ static void init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
 static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 			       unsigned long end, phys_addr_t phys,
 			       pgprot_t prot,
-			       phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+			       pgtable_alloc_t pgtable_alloc,
 			       int flags)
 {
 	unsigned long next;
@@ -252,7 +254,7 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 
 static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		    phys_addr_t phys, pgprot_t prot,
-		    phys_addr_t (*pgtable_alloc)(enum pgtable_type), int flags)
+		    pgtable_alloc_t pgtable_alloc, int flags)
 {
 	unsigned long next;
 
@@ -292,7 +294,7 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
 static int alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 			       unsigned long end, phys_addr_t phys,
 			       pgprot_t prot,
-			       phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+			       pgtable_alloc_t pgtable_alloc,
 			       int flags)
 {
 	int ret;
@@ -349,7 +351,7 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 
 static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
 			  phys_addr_t phys, pgprot_t prot,
-			  phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+			  pgtable_alloc_t pgtable_alloc,
 			  int flags)
 {
 	int ret = 0;
@@ -415,7 +417,7 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
 
 static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
 			  phys_addr_t phys, pgprot_t prot,
-			  phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+			  pgtable_alloc_t pgtable_alloc,
 			  int flags)
 {
 	int ret;
@@ -467,7 +469,7 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
 static int __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
 				       unsigned long virt, phys_addr_t size,
 				       pgprot_t prot,
-				       phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+				       pgtable_alloc_t pgtable_alloc,
 				       int flags)
 {
 	int ret;
@@ -500,7 +502,7 @@ static int __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
 static int __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 				unsigned long virt, phys_addr_t size,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+				pgtable_alloc_t pgtable_alloc,
 				int flags)
 {
 	int ret;
@@ -516,7 +518,7 @@ static int __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 static void early_create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 				     unsigned long virt, phys_addr_t size,
 				     pgprot_t prot,
-				     phys_addr_t (*pgtable_alloc)(enum pgtable_type),
+				     pgtable_alloc_t pgtable_alloc,
 				     int flags)
 {
 	int ret;
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

linear_map_split_to_ptes() currently allocates page tables while
splitting the linear mapping into PTEs under stop_machine() using GFP_ATOMIC.

This is fine for non-PREEMPT_RT configurations.
However, it becomes problematic on PREEMPT_RT, because
generic memory allocation/free APIs (e.g. pgtable_alloc(), __get_free_pages(), etc.)
cannot be called from a non-preemptible context, except for the _nolock() variants.
This is because generic memory allocation/free paths are sleepable,
as they rely on spin_lock(), which becomes sleepable on PREEMPT_RT.

In other words, even calling pgtable_alloc() with GFP_ATOMIC is not permitted
in __linear_map_split_to_pte() when it is executed by the stopper thread,
 where preemption is disabled on PREEMPT_RT.

To address this, the required number of page tables is first collected
and preallocated, and the preallocated page tables are then used
when splitting the linear mapping in __linear_map_split_to_pte().

Fixes: 3df6979d222b ("arm64: mm: split linear mapping if BBML2 unsupported on secondary CPUs")
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
---
 arch/arm64/mm/mmu.c | 202 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 164 insertions(+), 38 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4b4908ae189b..120874a2d35b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -529,18 +529,14 @@ static void early_create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 		panic("Failed to create page tables\n");
 }
 
-static phys_addr_t __pgd_pgtable_alloc(struct mm_struct *mm, gfp_t gfp,
-				       enum pgtable_type pgtable_type)
-{
-	/* Page is zeroed by init_clear_pgtable() so don't duplicate effort. */
-	struct ptdesc *ptdesc = pagetable_alloc(gfp & ~__GFP_ZERO, 0);
-	phys_addr_t pa;
-
-	if (!ptdesc)
-		return INVALID_PHYS_ADDR;
-
-	pa = page_to_phys(ptdesc_page(ptdesc));
+static struct ptdesc **split_pgtables;
+static unsigned long split_pgtables_count;
+static unsigned long split_pgtables_idx;
 
+static void __pgd_pgtable_init(struct mm_struct *mm,
+			       struct ptdesc *ptdesc,
+			       enum pgtable_type pgtable_type)
+{
 	switch (pgtable_type) {
 	case TABLE_PTE:
 		BUG_ON(!pagetable_pte_ctor(mm, ptdesc));
@@ -555,26 +551,49 @@ static phys_addr_t __pgd_pgtable_alloc(struct mm_struct *mm, gfp_t gfp,
 		pagetable_p4d_ctor(ptdesc);
 		break;
 	}
-
-	return pa;
 }
 
-static phys_addr_t
-pgd_pgtable_alloc_init_mm_gfp(enum pgtable_type pgtable_type, gfp_t gfp)
+static phys_addr_t __pgd_pgtable_alloc(struct mm_struct *mm,
+				       enum pgtable_type pgtable_type)
 {
-	return __pgd_pgtable_alloc(&init_mm, gfp, pgtable_type);
+	/* Page is zeroed by init_clear_pgtable() so don't duplicate effort. */
+	struct ptdesc *ptdesc = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
+
+	if (!ptdesc)
+		return INVALID_PHYS_ADDR;
+
+	__pgd_pgtable_init(mm, ptdesc, pgtable_type);
+
+	return page_to_phys(ptdesc_page(ptdesc));
 }
 
-static phys_addr_t __maybe_unused
+static phys_addr_t
 pgd_pgtable_alloc_init_mm(enum pgtable_type pgtable_type)
 {
-	return pgd_pgtable_alloc_init_mm_gfp(pgtable_type, GFP_PGTABLE_KERNEL);
+	return __pgd_pgtable_alloc(&init_mm, pgtable_type);
 }
 
 static phys_addr_t
 pgd_pgtable_alloc_special_mm(enum pgtable_type pgtable_type)
 {
-	return  __pgd_pgtable_alloc(NULL, GFP_PGTABLE_KERNEL, pgtable_type);
+	return  __pgd_pgtable_alloc(NULL, pgtable_type);
+}
+
+static phys_addr_t
+pgd_pgtable_get_preallocated(enum pgtable_type pgtable_type)
+{
+	struct ptdesc *ptdesc;
+
+	if (WARN_ON(split_pgtables_idx >= split_pgtables_count))
+		return INVALID_PHYS_ADDR;
+
+	ptdesc = split_pgtables[split_pgtables_idx++];
+	if (!ptdesc)
+		return INVALID_PHYS_ADDR;
+
+	__pgd_pgtable_init(&init_mm, ptdesc, pgtable_type);
+
+	return page_to_phys(ptdesc_page(ptdesc));
 }
 
 static void split_contpte(pte_t *ptep)
@@ -586,7 +605,8 @@ static void split_contpte(pte_t *ptep)
 		__set_pte(ptep, pte_mknoncont(__ptep_get(ptep)));
 }
 
-static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
+static int split_pmd(pmd_t *pmdp, pmd_t pmd, pgtable_alloc_t pgtable_alloc,
+		     bool to_cont)
 {
 	pmdval_t tableprot = PMD_TYPE_TABLE | PMD_TABLE_UXN | PMD_TABLE_AF;
 	unsigned long pfn = pmd_pfn(pmd);
@@ -595,7 +615,7 @@ static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
 	pte_t *ptep;
 	int i;
 
-	pte_phys = pgd_pgtable_alloc_init_mm_gfp(TABLE_PTE, gfp);
+	pte_phys = pgtable_alloc(TABLE_PTE);
 	if (pte_phys == INVALID_PHYS_ADDR)
 		return -ENOMEM;
 	ptep = (pte_t *)phys_to_virt(pte_phys);
@@ -630,7 +650,8 @@ static void split_contpmd(pmd_t *pmdp)
 		set_pmd(pmdp, pmd_mknoncont(pmdp_get(pmdp)));
 }
 
-static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
+static int split_pud(pud_t *pudp, pud_t pud, pgtable_alloc_t pgtable_alloc,
+		     bool to_cont)
 {
 	pudval_t tableprot = PUD_TYPE_TABLE | PUD_TABLE_UXN | PUD_TABLE_AF;
 	unsigned int step = PMD_SIZE >> PAGE_SHIFT;
@@ -640,7 +661,7 @@ static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
 	pmd_t *pmdp;
 	int i;
 
-	pmd_phys = pgd_pgtable_alloc_init_mm_gfp(TABLE_PMD, gfp);
+	pmd_phys = pgtable_alloc(TABLE_PMD);
 	if (pmd_phys == INVALID_PHYS_ADDR)
 		return -ENOMEM;
 	pmdp = (pmd_t *)phys_to_virt(pmd_phys);
@@ -709,7 +730,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
 	if (!pud_present(pud))
 		goto out;
 	if (pud_leaf(pud)) {
-		ret = split_pud(pudp, pud, GFP_PGTABLE_KERNEL, true);
+		ret = split_pud(pudp, pud, pgd_pgtable_alloc_init_mm, true);
 		if (ret)
 			goto out;
 	}
@@ -734,7 +755,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
 		 */
 		if (ALIGN_DOWN(addr, PMD_SIZE) == addr)
 			goto out;
-		ret = split_pmd(pmdp, pmd, GFP_PGTABLE_KERNEL, true);
+		ret = split_pmd(pmdp, pmd, pgd_pgtable_alloc_init_mm, true);
 		if (ret)
 			goto out;
 	}
@@ -832,12 +853,12 @@ int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
 static int split_to_ptes_pud_entry(pud_t *pudp, unsigned long addr,
 				   unsigned long next, struct mm_walk *walk)
 {
-	gfp_t gfp = *(gfp_t *)walk->private;
+	pgtable_alloc_t *pgtable_alloc = walk->private;
 	pud_t pud = pudp_get(pudp);
 	int ret = 0;
 
 	if (pud_leaf(pud))
-		ret = split_pud(pudp, pud, gfp, false);
+		ret = split_pud(pudp, pud, pgtable_alloc, false);
 
 	return ret;
 }
@@ -845,14 +866,14 @@ static int split_to_ptes_pud_entry(pud_t *pudp, unsigned long addr,
 static int split_to_ptes_pmd_entry(pmd_t *pmdp, unsigned long addr,
 				   unsigned long next, struct mm_walk *walk)
 {
-	gfp_t gfp = *(gfp_t *)walk->private;
+	pgtable_alloc_t *pgtable_alloc = walk->private;
 	pmd_t pmd = pmdp_get(pmdp);
 	int ret = 0;
 
 	if (pmd_leaf(pmd)) {
 		if (pmd_cont(pmd))
 			split_contpmd(pmdp);
-		ret = split_pmd(pmdp, pmd, gfp, false);
+		ret = split_pmd(pmdp, pmd, pgtable_alloc, false);
 
 		/*
 		 * We have split the pmd directly to ptes so there is no need to
@@ -881,13 +902,15 @@ static const struct mm_walk_ops split_to_ptes_ops = {
 	.pte_entry	= split_to_ptes_pte_entry,
 };
 
-static int range_split_to_ptes(unsigned long start, unsigned long end, gfp_t gfp)
+static int range_split_to_ptes(unsigned long start, unsigned long end,
+			       pgtable_alloc_t pgtable_alloc)
 {
 	int ret;
 
 	arch_enter_lazy_mmu_mode();
 	ret = walk_kernel_page_table_range_lockless(start, end,
-					&split_to_ptes_ops, NULL, &gfp);
+						    &split_to_ptes_ops, NULL,
+						    pgtable_alloc);
 	arch_leave_lazy_mmu_mode();
 
 	return ret;
@@ -904,6 +927,103 @@ static void __init init_idmap_kpti_bbml2_flag(void)
 	smp_mb();
 }
 
+static int __init
+collect_to_split_pud_entry(pud_t *pudp, unsigned long addr,
+			   unsigned long next, struct mm_walk *walk)
+{
+	pud_t pud = pudp_get(pudp);
+
+	if (pud_leaf(pud)) {
+		split_pgtables_count += 1 + PTRS_PER_PMD;
+		walk->action = ACTION_CONTINUE;
+	}
+
+	return 0;
+}
+
+static int __init
+collect_to_split_pmd_entry(pmd_t *pmdp, unsigned long addr,
+			   unsigned long next, struct mm_walk *walk)
+{
+	pmd_t pmd = pmdp_get(pmdp);
+
+	if (pmd_leaf(pmd))
+		split_pgtables_count++;
+
+	walk->action = ACTION_CONTINUE;
+
+	return 0;
+}
+
+static void __init linear_map_free_split_pgtables(void)
+{
+	int i;
+
+	if (!split_pgtables_count || !split_pgtables)
+		goto skip_free;
+
+	for (i = split_pgtables_idx; i < split_pgtables_count; i++) {
+		if (split_pgtables[i])
+			pagetable_free(split_pgtables[i]);
+	}
+
+	kvfree(split_pgtables);
+
+skip_free:
+	split_pgtables = NULL;
+	split_pgtables_count = 0;
+	split_pgtables_idx = 0;
+}
+
+static int __init linear_map_prealloc_split_pgtables(void)
+{
+	int ret, i;
+	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
+	unsigned long lend = PAGE_END;
+	unsigned long kstart = (unsigned long)lm_alias(_stext);
+	unsigned long kend = (unsigned long)lm_alias(__init_begin);
+
+	const struct mm_walk_ops collect_to_split_ops = {
+		.pud_entry	= collect_to_split_pud_entry,
+		.pmd_entry	= collect_to_split_pmd_entry
+	};
+
+	split_pgtables_idx = 0;
+	split_pgtables_count = 0;
+
+	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
+						    &collect_to_split_ops,
+						    NULL, NULL);
+	if (!ret)
+		ret = walk_kernel_page_table_range_lockless(kend, lend,
+							    &collect_to_split_ops,
+							    NULL, NULL);
+	if (ret || !split_pgtables_count)
+		goto error;
+
+	ret = -ENOMEM;
+
+	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
+				  GFP_KERNEL | __GFP_ZERO);
+	if (!split_pgtables)
+		goto error;
+
+	for (i = 0; i < split_pgtables_count; i++) {
+		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
+		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
+		if (!split_pgtables[i])
+			goto error;
+	}
+
+	ret = 0;
+
+error:
+	if (ret)
+		linear_map_free_split_pgtables();
+
+	return ret;
+}
+
 static int __init linear_map_split_to_ptes(void *__unused)
 {
 	/*
@@ -929,9 +1049,9 @@ static int __init linear_map_split_to_ptes(void *__unused)
 		 * PTE. The kernel alias remains static throughout runtime so
 		 * can continue to be safely mapped with large mappings.
 		 */
-		ret = range_split_to_ptes(lstart, kstart, GFP_ATOMIC);
+		ret = range_split_to_ptes(lstart, kstart, pgd_pgtable_get_preallocated);
 		if (!ret)
-			ret = range_split_to_ptes(kend, lend, GFP_ATOMIC);
+			ret = range_split_to_ptes(kend, lend, pgd_pgtable_get_preallocated);
 		if (ret)
 			panic("Failed to split linear map\n");
 		flush_tlb_kernel_range(lstart, lend);
@@ -964,10 +1084,16 @@ static int __init linear_map_split_to_ptes(void *__unused)
 
 void __init linear_map_maybe_split_to_ptes(void)
 {
-	if (linear_map_requires_bbml2 && !system_supports_bbml2_noabort()) {
-		init_idmap_kpti_bbml2_flag();
-		stop_machine(linear_map_split_to_ptes, NULL, cpu_online_mask);
-	}
+	if (!linear_map_requires_bbml2 || system_supports_bbml2_noabort())
+		return;
+
+	if (linear_map_prealloc_split_pgtables())
+		panic("Failed to split linear map\n");
+
+	init_idmap_kpti_bbml2_flag();
+	stop_machine(linear_map_split_to_ptes, NULL, cpu_online_mask);
+
+	linear_map_free_split_pgtables();
 }
 
 /*
@@ -1098,7 +1224,7 @@ bool arch_kfence_init_pool(void)
 		return true;
 
 	mutex_lock(&pgtable_split_lock);
-	ret = range_split_to_ptes(start, end, GFP_PGTABLE_KERNEL);
+	ret = range_split_to_ptes(start, end, pgd_pgtable_alloc_init_mm);
 	mutex_unlock(&pgtable_split_lock);
 
 	/*
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Will Deacon]

On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> +static int __init linear_map_prealloc_split_pgtables(void)
> +{
> +	int ret, i;
> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> +	unsigned long lend = PAGE_END;
> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> +
> +	const struct mm_walk_ops collect_to_split_ops = {
> +		.pud_entry	= collect_to_split_pud_entry,
> +		.pmd_entry	= collect_to_split_pmd_entry
> +	};

Why do we need to rewalk the page-table here instead of collating the
number of block mappings we put down when creating the linear map in
the first place?

> +	split_pgtables_idx = 0;
> +	split_pgtables_count = 0;
> +
> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> +						    &collect_to_split_ops,
> +						    NULL, NULL);
> +	if (!ret)
> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> +							    &collect_to_split_ops,
> +							    NULL, NULL);
> +	if (ret || !split_pgtables_count)
> +		goto error;
> +
> +	ret = -ENOMEM;
> +
> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> +				  GFP_KERNEL | __GFP_ZERO);
> +	if (!split_pgtables)
> +		goto error;
> +
> +	for (i = 0; i < split_pgtables_count; i++) {
> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> +		if (!split_pgtables[i])
> +			goto error;

This looks potentially expensive on the boot path and only gets worse as
the amount of memory grows. Maybe we should predicate this preallocation
on preempt-rt?

Will

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Will,

> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> > +static int __init linear_map_prealloc_split_pgtables(void)
> > +{
> > +	int ret, i;
> > +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> > +	unsigned long lend = PAGE_END;
> > +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> > +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> > +
> > +	const struct mm_walk_ops collect_to_split_ops = {
> > +		.pud_entry	= collect_to_split_pud_entry,
> > +		.pmd_entry	= collect_to_split_pmd_entry
> > +	};
>
> Why do we need to rewalk the page-table here instead of collating the
> number of block mappings we put down when creating the linear map in
> the first place?

First, linear alias of the [_text, __init_begin) is not a target for
the split and it also seems strange to me to add code inside alloc_init_XXX()
that both checks an address range and counts to get the number of block mappings.

Second, for a future feature,
I hope to add some code to split "specfic" area to be spilt e.x)
to set a specific pkey for specific area.

In this case, it's useful to rewalk the page-table with the specific
range to get the number of block mapping.

>
> > +	split_pgtables_idx = 0;
> > +	split_pgtables_count = 0;
> > +
> > +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> > +						    &collect_to_split_ops,
> > +						    NULL, NULL);
> > +	if (!ret)
> > +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> > +							    &collect_to_split_ops,
> > +							    NULL, NULL);
> > +	if (ret || !split_pgtables_count)
> > +		goto error;
> > +
> > +	ret = -ENOMEM;
> > +
> > +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> > +				  GFP_KERNEL | __GFP_ZERO);
> > +	if (!split_pgtables)
> > +		goto error;
> > +
> > +	for (i = 0; i < split_pgtables_count; i++) {
> > +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> > +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> > +		if (!split_pgtables[i])
> > +			goto error;
>
> This looks potentially expensive on the boot path and only gets worse as
> the amount of memory grows. Maybe we should predicate this preallocation
> on preempt-rt?

Agree. then I'll apply pre-allocation with PREEMPT_RT only.

Thanks for your review.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

On 19/01/2026 21:24, Yeoreum Yun wrote:
> Hi Will,
> 
>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>> +{
>>> +	int ret, i;
>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>> +	unsigned long lend = PAGE_END;
>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>> +
>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>> +		.pud_entry	= collect_to_split_pud_entry,
>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>> +	};
>>
>> Why do we need to rewalk the page-table here instead of collating the
>> number of block mappings we put down when creating the linear map in
>> the first place?

That's a good point; perhaps we can reuse the counters that this series introduces?

https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/

> 
> First, linear alias of the [_text, __init_begin) is not a target for
> the split and it also seems strange to me to add code inside alloc_init_XXX()
> that both checks an address range and counts to get the number of block mappings.
> 
> Second, for a future feature,
> I hope to add some code to split "specfic" area to be spilt e.x)
> to set a specific pkey for specific area.

Could you give more detail on this? My working assumption is that either the
system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
linear map. If it does, we already have logic to split parts of the linear map
when needed.

> 
> In this case, it's useful to rewalk the page-table with the specific
> range to get the number of block mapping.
> 
>>
>>> +	split_pgtables_idx = 0;
>>> +	split_pgtables_count = 0;
>>> +
>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>> +						    &collect_to_split_ops,
>>> +						    NULL, NULL);
>>> +	if (!ret)
>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>> +							    &collect_to_split_ops,
>>> +							    NULL, NULL);
>>> +	if (ret || !split_pgtables_count)
>>> +		goto error;
>>> +
>>> +	ret = -ENOMEM;
>>> +
>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>> +				  GFP_KERNEL | __GFP_ZERO);
>>> +	if (!split_pgtables)
>>> +		goto error;
>>> +
>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>> +		if (!split_pgtables[i])
>>> +			goto error;
>>
>> This looks potentially expensive on the boot path and only gets worse as
>> the amount of memory grows. Maybe we should predicate this preallocation
>> on preempt-rt?
> 
> Agree. then I'll apply pre-allocation with PREEMPT_RT only.

I guess I'm missing something obvious but I don't understand the problem here...
We are only deferring the allocation of all these pgtables, so the cost is
neutral surely? Had we correctly guessed that the system doesn't support BBML2
earlier, we would have had to allocate all these pgtables earlier.

Another way to look at it is that we are still allocating the same number of
pgtables in the existing fallback path, it's just that we are doing it inside
the stop_machine().

My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
with significantly less testing...

Thanks,
Ryan

> 
> Thanks for your review.
> 
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Ryan
> On 19/01/2026 21:24, Yeoreum Yun wrote:
> > Hi Will,
> >
> >> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> >>> +static int __init linear_map_prealloc_split_pgtables(void)
> >>> +{
> >>> +	int ret, i;
> >>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> >>> +	unsigned long lend = PAGE_END;
> >>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> >>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> >>> +
> >>> +	const struct mm_walk_ops collect_to_split_ops = {
> >>> +		.pud_entry	= collect_to_split_pud_entry,
> >>> +		.pmd_entry	= collect_to_split_pmd_entry
> >>> +	};
> >>
> >> Why do we need to rewalk the page-table here instead of collating the
> >> number of block mappings we put down when creating the linear map in
> >> the first place?
>
> That's a good point; perhaps we can reuse the counters that this series introduces?
>
> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>
> >
> > First, linear alias of the [_text, __init_begin) is not a target for
> > the split and it also seems strange to me to add code inside alloc_init_XXX()
> > that both checks an address range and counts to get the number of block mappings.
> >
> > Second, for a future feature,
> > I hope to add some code to split "specfic" area to be spilt e.x)
> > to set a specific pkey for specific area.
>
> Could you give more detail on this? My working assumption is that either the
> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> linear map. If it does, we already have logic to split parts of the linear map
> when needed.

This is not for a linear mapping case. but for a "kernel text area".
As a draft, I want to mark some of kernel code can executable
both kernel and eBPF program.
(I'm trying to make eBPF program non-executable kernel code directly
with POE feature).
For this "executable area" both of kernel and eBPF program
-- typical example is exception entry, It need to split that specific
range and mark them with special POE index.

>
> >
> > In this case, it's useful to rewalk the page-table with the specific
> > range to get the number of block mapping.
> >
> >>
> >>> +	split_pgtables_idx = 0;
> >>> +	split_pgtables_count = 0;
> >>> +
> >>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> >>> +						    &collect_to_split_ops,
> >>> +						    NULL, NULL);
> >>> +	if (!ret)
> >>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> >>> +							    &collect_to_split_ops,
> >>> +							    NULL, NULL);
> >>> +	if (ret || !split_pgtables_count)
> >>> +		goto error;
> >>> +
> >>> +	ret = -ENOMEM;
> >>> +
> >>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> >>> +				  GFP_KERNEL | __GFP_ZERO);
> >>> +	if (!split_pgtables)
> >>> +		goto error;
> >>> +
> >>> +	for (i = 0; i < split_pgtables_count; i++) {
> >>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> >>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> >>> +		if (!split_pgtables[i])
> >>> +			goto error;
> >>
> >> This looks potentially expensive on the boot path and only gets worse as
> >> the amount of memory grows. Maybe we should predicate this preallocation
> >> on preempt-rt?
> >
> > Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>
> I guess I'm missing something obvious but I don't understand the problem here...
> We are only deferring the allocation of all these pgtables, so the cost is
> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> earlier, we would have had to allocate all these pgtables earlier.
>
> Another way to look at it is that we are still allocating the same number of
> pgtables in the existing fallback path, it's just that we are doing it inside
> the stop_machine().
>
> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> with significantly less testing...

IIUC, Will's mention is additional memory allocation for
"split_pgtables" where saved "pre-allocate" page tables.
As the memory increase, definitely this size would increase the cost.

And this cost need not to burden for !PREEMPT_RT since
it can use memory allocation in stop_machine() with GFP_ATOMIC.

But I also agree in the aspect that if that cost not much of huge,
It's also convincing and additionally, as I mentioned in another thread,
It would be good not to give a hallucination GFP_ATOMIC is fine for
everywhere even in the PREEMPT_RT.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

On 20/01/2026 09:29, Yeoreum Yun wrote:
> Hi Ryan
>> On 19/01/2026 21:24, Yeoreum Yun wrote:
>>> Hi Will,
>>>
>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>>>> +{
>>>>> +	int ret, i;
>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>>>> +	unsigned long lend = PAGE_END;
>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>>>> +
>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>>>> +		.pud_entry	= collect_to_split_pud_entry,
>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>>>> +	};
>>>>
>>>> Why do we need to rewalk the page-table here instead of collating the
>>>> number of block mappings we put down when creating the linear map in
>>>> the first place?
>>
>> That's a good point; perhaps we can reuse the counters that this series introduces?
>>
>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>>
>>>
>>> First, linear alias of the [_text, __init_begin) is not a target for
>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
>>> that both checks an address range and counts to get the number of block mappings.
>>>
>>> Second, for a future feature,
>>> I hope to add some code to split "specfic" area to be spilt e.x)
>>> to set a specific pkey for specific area.
>>
>> Could you give more detail on this? My working assumption is that either the
>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
>> linear map. If it does, we already have logic to split parts of the linear map
>> when needed.
> 
> This is not for a linear mapping case. but for a "kernel text area".
> As a draft, I want to mark some of kernel code can executable
> both kernel and eBPF program.
> (I'm trying to make eBPF program non-executable kernel code directly
> with POE feature).
> For this "executable area" both of kernel and eBPF program
> -- typical example is exception entry, It need to split that specific
> range and mark them with special POE index.

Ahh yes, I recall you mentioning this a while back (although I confess all the
deatils have fallen out of my head). You'd need to make sure you're definitely
not splitting an area of text that the secondary CPUs are executing while they
are being held in the pen, since at least one of those CPUs doesn't support BBML2.

> 
>>
>>>
>>> In this case, it's useful to rewalk the page-table with the specific
>>> range to get the number of block mapping.
>>>
>>>>
>>>>> +	split_pgtables_idx = 0;
>>>>> +	split_pgtables_count = 0;
>>>>> +
>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>>>> +						    &collect_to_split_ops,
>>>>> +						    NULL, NULL);
>>>>> +	if (!ret)
>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>>>> +							    &collect_to_split_ops,
>>>>> +							    NULL, NULL);
>>>>> +	if (ret || !split_pgtables_count)
>>>>> +		goto error;
>>>>> +
>>>>> +	ret = -ENOMEM;
>>>>> +
>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>>>> +				  GFP_KERNEL | __GFP_ZERO);
>>>>> +	if (!split_pgtables)
>>>>> +		goto error;
>>>>> +
>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>>>> +		if (!split_pgtables[i])
>>>>> +			goto error;
>>>>
>>>> This looks potentially expensive on the boot path and only gets worse as
>>>> the amount of memory grows. Maybe we should predicate this preallocation
>>>> on preempt-rt?
>>>
>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>>
>> I guess I'm missing something obvious but I don't understand the problem here...
>> We are only deferring the allocation of all these pgtables, so the cost is
>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
>> earlier, we would have had to allocate all these pgtables earlier.
>>
>> Another way to look at it is that we are still allocating the same number of
>> pgtables in the existing fallback path, it's just that we are doing it inside
>> the stop_machine().
>>
>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
>> with significantly less testing...
> 
> IIUC, Will's mention is additional memory allocation for
> "split_pgtables" where saved "pre-allocate" page tables.
> As the memory increase, definitely this size would increase the cost.

Err, so you're referring to the extra kvmalloc()? I don't think that's a big
deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?

I suspect we have both misunderstood Will's point...

Thanks,
Ryan

> 
> And this cost need not to burden for !PREEMPT_RT since
> it can use memory allocation in stop_machine() with GFP_ATOMIC.
> 
> But I also agree in the aspect that if that cost not much of huge,
> It's also convincing and additionally, as I mentioned in another thread,
> It would be good not to give a hallucination GFP_ATOMIC is fine for
> everywhere even in the PREEMPT_RT.
> 
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

> >>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> >>>>> +static int __init linear_map_prealloc_split_pgtables(void)
> >>>>> +{
> >>>>> +	int ret, i;
> >>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> >>>>> +	unsigned long lend = PAGE_END;
> >>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> >>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> >>>>> +
> >>>>> +	const struct mm_walk_ops collect_to_split_ops = {
> >>>>> +		.pud_entry	= collect_to_split_pud_entry,
> >>>>> +		.pmd_entry	= collect_to_split_pmd_entry
> >>>>> +	};
> >>>>
> >>>> Why do we need to rewalk the page-table here instead of collating the
> >>>> number of block mappings we put down when creating the linear map in
> >>>> the first place?
> >>
> >> That's a good point; perhaps we can reuse the counters that this series introduces?
> >>
> >> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> >>
> >>>
> >>> First, linear alias of the [_text, __init_begin) is not a target for
> >>> the split and it also seems strange to me to add code inside alloc_init_XXX()
> >>> that both checks an address range and counts to get the number of block mappings.
> >>>
> >>> Second, for a future feature,
> >>> I hope to add some code to split "specfic" area to be spilt e.x)
> >>> to set a specific pkey for specific area.
> >>
> >> Could you give more detail on this? My working assumption is that either the
> >> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> >> linear map. If it does, we already have logic to split parts of the linear map
> >> when needed.
> >
> > This is not for a linear mapping case. but for a "kernel text area".
> > As a draft, I want to mark some of kernel code can executable
> > both kernel and eBPF program.
> > (I'm trying to make eBPF program non-executable kernel code directly
> > with POE feature).
> > For this "executable area" both of kernel and eBPF program
> > -- typical example is exception entry, It need to split that specific
> > range and mark them with special POE index.
>
> Ahh yes, I recall you mentioning this a while back (although I confess all the
> deatils have fallen out of my head). You'd need to make sure you're definitely
> not splitting an area of text that the secondary CPUs are executing while they
> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
>

Absoultely. Anyway for that feature, I hope to sustain the current
way -- collect, pre-allocate and use them for specific ranges.

> >
> >>
> >>>
> >>> In this case, it's useful to rewalk the page-table with the specific
> >>> range to get the number of block mapping.
> >>>
> >>>>
> >>>>> +	split_pgtables_idx = 0;
> >>>>> +	split_pgtables_count = 0;
> >>>>> +
> >>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> >>>>> +						    &collect_to_split_ops,
> >>>>> +						    NULL, NULL);
> >>>>> +	if (!ret)
> >>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> >>>>> +							    &collect_to_split_ops,
> >>>>> +							    NULL, NULL);
> >>>>> +	if (ret || !split_pgtables_count)
> >>>>> +		goto error;
> >>>>> +
> >>>>> +	ret = -ENOMEM;
> >>>>> +
> >>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> >>>>> +				  GFP_KERNEL | __GFP_ZERO);
> >>>>> +	if (!split_pgtables)
> >>>>> +		goto error;
> >>>>> +
> >>>>> +	for (i = 0; i < split_pgtables_count; i++) {
> >>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> >>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> >>>>> +		if (!split_pgtables[i])
> >>>>> +			goto error;
> >>>>
> >>>> This looks potentially expensive on the boot path and only gets worse as
> >>>> the amount of memory grows. Maybe we should predicate this preallocation
> >>>> on preempt-rt?
> >>>
> >>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> >>
> >> I guess I'm missing something obvious but I don't understand the problem here...
> >> We are only deferring the allocation of all these pgtables, so the cost is
> >> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> >> earlier, we would have had to allocate all these pgtables earlier.
> >>
> >> Another way to look at it is that we are still allocating the same number of
> >> pgtables in the existing fallback path, it's just that we are doing it inside
> >> the stop_machine().
> >>
> >> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> >> with significantly less testing...
> >
> > IIUC, Will's mention is additional memory allocation for
> > "split_pgtables" where saved "pre-allocate" page tables.
> > As the memory increase, definitely this size would increase the cost.
>
> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
>
> I suspect we have both misunderstood Will's point...

Might be.. sorry for my misunderstanding.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Will Deacon]

On Tue, Jan 20, 2026 at 10:40:30AM +0000, Ryan Roberts wrote:
> On 20/01/2026 09:29, Yeoreum Yun wrote:
> > Hi Ryan
> >> On 19/01/2026 21:24, Yeoreum Yun wrote:
> >>> Hi Will,
> >>>
> >>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> >>>>> +static int __init linear_map_prealloc_split_pgtables(void)
> >>>>> +{
> >>>>> +	int ret, i;
> >>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> >>>>> +	unsigned long lend = PAGE_END;
> >>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> >>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> >>>>> +
> >>>>> +	const struct mm_walk_ops collect_to_split_ops = {
> >>>>> +		.pud_entry	= collect_to_split_pud_entry,
> >>>>> +		.pmd_entry	= collect_to_split_pmd_entry
> >>>>> +	};
> >>>>
> >>>> Why do we need to rewalk the page-table here instead of collating the
> >>>> number of block mappings we put down when creating the linear map in
> >>>> the first place?
> >>
> >> That's a good point; perhaps we can reuse the counters that this series introduces?
> >>
> >> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> >>
> >>>
> >>> First, linear alias of the [_text, __init_begin) is not a target for
> >>> the split and it also seems strange to me to add code inside alloc_init_XXX()
> >>> that both checks an address range and counts to get the number of block mappings.
> >>>
> >>> Second, for a future feature,
> >>> I hope to add some code to split "specfic" area to be spilt e.x)
> >>> to set a specific pkey for specific area.
> >>
> >> Could you give more detail on this? My working assumption is that either the
> >> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> >> linear map. If it does, we already have logic to split parts of the linear map
> >> when needed.
> > 
> > This is not for a linear mapping case. but for a "kernel text area".
> > As a draft, I want to mark some of kernel code can executable
> > both kernel and eBPF program.
> > (I'm trying to make eBPF program non-executable kernel code directly
> > with POE feature).
> > For this "executable area" both of kernel and eBPF program
> > -- typical example is exception entry, It need to split that specific
> > range and mark them with special POE index.
> 
> Ahh yes, I recall you mentioning this a while back (although I confess all the
> deatils have fallen out of my head). You'd need to make sure you're definitely
> not splitting an area of text that the secondary CPUs are executing while they
> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
> 
> > 
> >>
> >>>
> >>> In this case, it's useful to rewalk the page-table with the specific
> >>> range to get the number of block mapping.
> >>>
> >>>>
> >>>>> +	split_pgtables_idx = 0;
> >>>>> +	split_pgtables_count = 0;
> >>>>> +
> >>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> >>>>> +						    &collect_to_split_ops,
> >>>>> +						    NULL, NULL);
> >>>>> +	if (!ret)
> >>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> >>>>> +							    &collect_to_split_ops,
> >>>>> +							    NULL, NULL);
> >>>>> +	if (ret || !split_pgtables_count)
> >>>>> +		goto error;

Just noticed this, but why do we check '!split_pgtables_count' here?
if the page-table is already somehow mapped at page granularity, that
doesn't necessarily sound like a fatal error to me.

> >>>>> +
> >>>>> +	ret = -ENOMEM;
> >>>>> +
> >>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> >>>>> +				  GFP_KERNEL | __GFP_ZERO);
> >>>>> +	if (!split_pgtables)
> >>>>> +		goto error;
> >>>>> +
> >>>>> +	for (i = 0; i < split_pgtables_count; i++) {
> >>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> >>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> >>>>> +		if (!split_pgtables[i])
> >>>>> +			goto error;
> >>>>
> >>>> This looks potentially expensive on the boot path and only gets worse as
> >>>> the amount of memory grows. Maybe we should predicate this preallocation
> >>>> on preempt-rt?
> >>>
> >>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> >>
> >> I guess I'm missing something obvious but I don't understand the problem here...
> >> We are only deferring the allocation of all these pgtables, so the cost is
> >> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> >> earlier, we would have had to allocate all these pgtables earlier.
> >>
> >> Another way to look at it is that we are still allocating the same number of
> >> pgtables in the existing fallback path, it's just that we are doing it inside
> >> the stop_machine().
> >>
> >> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> >> with significantly less testing...
> > 
> > IIUC, Will's mention is additional memory allocation for
> > "split_pgtables" where saved "pre-allocate" page tables.
> > As the memory increase, definitely this size would increase the cost.
> 
> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?

Right, it was the page-table pages I was worried about not the array of
pointers.

> I suspect we have both misunderstood Will's point...

I probably just got confused by linear_map_free_split_pgtables() as it
has logic to free unused page-table pages between 'split_pgtables_idx'
and 'split_pgtables_count', implying that we can over-allocate.

If that is only needed for the error path in
linear_map_prealloc_split_pgtables(), then perhaps that part should be
inlined to deal with the case where we fail to allocate part way through.

Will

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Will,

> > On 20/01/2026 09:29, Yeoreum Yun wrote:
> > > Hi Ryan
> > >> On 19/01/2026 21:24, Yeoreum Yun wrote:
> > >>> Hi Will,
> > >>>
> > >>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> > >>>>> +static int __init linear_map_prealloc_split_pgtables(void)
> > >>>>> +{
> > >>>>> +	int ret, i;
> > >>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> > >>>>> +	unsigned long lend = PAGE_END;
> > >>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> > >>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> > >>>>> +
> > >>>>> +	const struct mm_walk_ops collect_to_split_ops = {
> > >>>>> +		.pud_entry	= collect_to_split_pud_entry,
> > >>>>> +		.pmd_entry	= collect_to_split_pmd_entry
> > >>>>> +	};
> > >>>>
> > >>>> Why do we need to rewalk the page-table here instead of collating the
> > >>>> number of block mappings we put down when creating the linear map in
> > >>>> the first place?
> > >>
> > >> That's a good point; perhaps we can reuse the counters that this series introduces?
> > >>
> > >> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> > >>
> > >>>
> > >>> First, linear alias of the [_text, __init_begin) is not a target for
> > >>> the split and it also seems strange to me to add code inside alloc_init_XXX()
> > >>> that both checks an address range and counts to get the number of block mappings.
> > >>>
> > >>> Second, for a future feature,
> > >>> I hope to add some code to split "specfic" area to be spilt e.x)
> > >>> to set a specific pkey for specific area.
> > >>
> > >> Could you give more detail on this? My working assumption is that either the
> > >> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> > >> linear map. If it does, we already have logic to split parts of the linear map
> > >> when needed.
> > >
> > > This is not for a linear mapping case. but for a "kernel text area".
> > > As a draft, I want to mark some of kernel code can executable
> > > both kernel and eBPF program.
> > > (I'm trying to make eBPF program non-executable kernel code directly
> > > with POE feature).
> > > For this "executable area" both of kernel and eBPF program
> > > -- typical example is exception entry, It need to split that specific
> > > range and mark them with special POE index.
> >
> > Ahh yes, I recall you mentioning this a while back (although I confess all the
> > deatils have fallen out of my head). You'd need to make sure you're definitely
> > not splitting an area of text that the secondary CPUs are executing while they
> > are being held in the pen, since at least one of those CPUs doesn't support BBML2.
> >
> > >
> > >>
> > >>>
> > >>> In this case, it's useful to rewalk the page-table with the specific
> > >>> range to get the number of block mapping.
> > >>>
> > >>>>
> > >>>>> +	split_pgtables_idx = 0;
> > >>>>> +	split_pgtables_count = 0;
> > >>>>> +
> > >>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> > >>>>> +						    &collect_to_split_ops,
> > >>>>> +						    NULL, NULL);
> > >>>>> +	if (!ret)
> > >>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> > >>>>> +							    &collect_to_split_ops,
> > >>>>> +							    NULL, NULL);
> > >>>>> +	if (ret || !split_pgtables_count)
> > >>>>> +		goto error;
>
> Just noticed this, but why do we check '!split_pgtables_count' here?
> if the page-table is already somehow mapped at page granularity, that
> doesn't necessarily sound like a fatal error to me.

!split_pgtables_count is not a "error" case, but just to skip
the remaining logic.
Might the label name "error" makes you confused?

>
> > >>>>> +
> > >>>>> +	ret = -ENOMEM;
> > >>>>> +
> > >>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> > >>>>> +				  GFP_KERNEL | __GFP_ZERO);
> > >>>>> +	if (!split_pgtables)
> > >>>>> +		goto error;
> > >>>>> +
> > >>>>> +	for (i = 0; i < split_pgtables_count; i++) {
> > >>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> > >>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> > >>>>> +		if (!split_pgtables[i])
> > >>>>> +			goto error;
> > >>>>
> > >>>> This looks potentially expensive on the boot path and only gets worse as
> > >>>> the amount of memory grows. Maybe we should predicate this preallocation
> > >>>> on preempt-rt?
> > >>>
> > >>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> > >>
> > >> I guess I'm missing something obvious but I don't understand the problem here...
> > >> We are only deferring the allocation of all these pgtables, so the cost is
> > >> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> > >> earlier, we would have had to allocate all these pgtables earlier.
> > >>
> > >> Another way to look at it is that we are still allocating the same number of
> > >> pgtables in the existing fallback path, it's just that we are doing it inside
> > >> the stop_machine().
> > >>
> > >> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> > >> with significantly less testing...
> > >
> > > IIUC, Will's mention is additional memory allocation for
> > > "split_pgtables" where saved "pre-allocate" page tables.
> > > As the memory increase, definitely this size would increase the cost.
> >
> > Err, so you're referring to the extra kvmalloc()? I don't think that's a big
> > deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
>
> Right, it was the page-table pages I was worried about not the array of
> pointers.
>
> > I suspect we have both misunderstood Will's point...
>
> I probably just got confused by linear_map_free_split_pgtables() as it
> has logic to free unused page-table pages between 'split_pgtables_idx'
> and 'split_pgtables_count', implying that we can over-allocate.
>
> If that is only needed for the error path in
> linear_map_prealloc_split_pgtables(), then perhaps that part should be
> inlined to deal with the case where we fail to allocate part way through.
>
> Will

This is not for the case of "over-allocate" at the first time.
But for a some case that another CPU caused a split between figuring
out the required number of tables and actually doing the full split
(though it seems unlikely) which Ryan point out in here:
  - https://lore.kernel.org/all/73ced1db-a2e2-49ea-927e-9fc4a30e771e@arm.com/

So, it's also required for case of success too.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

On 20/01/2026 15:53, Will Deacon wrote:
> On Tue, Jan 20, 2026 at 10:40:30AM +0000, Ryan Roberts wrote:
>> On 20/01/2026 09:29, Yeoreum Yun wrote:
>>> Hi Ryan
>>>> On 19/01/2026 21:24, Yeoreum Yun wrote:
>>>>> Hi Will,
>>>>>
>>>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>>>>>> +{
>>>>>>> +	int ret, i;
>>>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>>>>>> +	unsigned long lend = PAGE_END;
>>>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>>>>>> +
>>>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>>>>>> +		.pud_entry	= collect_to_split_pud_entry,
>>>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>>>>>> +	};
>>>>>>
>>>>>> Why do we need to rewalk the page-table here instead of collating the
>>>>>> number of block mappings we put down when creating the linear map in
>>>>>> the first place?
>>>>
>>>> That's a good point; perhaps we can reuse the counters that this series introduces?
>>>>
>>>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>>>>
>>>>>
>>>>> First, linear alias of the [_text, __init_begin) is not a target for
>>>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
>>>>> that both checks an address range and counts to get the number of block mappings.
>>>>>
>>>>> Second, for a future feature,
>>>>> I hope to add some code to split "specfic" area to be spilt e.x)
>>>>> to set a specific pkey for specific area.
>>>>
>>>> Could you give more detail on this? My working assumption is that either the
>>>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
>>>> linear map. If it does, we already have logic to split parts of the linear map
>>>> when needed.
>>>
>>> This is not for a linear mapping case. but for a "kernel text area".
>>> As a draft, I want to mark some of kernel code can executable
>>> both kernel and eBPF program.
>>> (I'm trying to make eBPF program non-executable kernel code directly
>>> with POE feature).
>>> For this "executable area" both of kernel and eBPF program
>>> -- typical example is exception entry, It need to split that specific
>>> range and mark them with special POE index.
>>
>> Ahh yes, I recall you mentioning this a while back (although I confess all the
>> deatils have fallen out of my head). You'd need to make sure you're definitely
>> not splitting an area of text that the secondary CPUs are executing while they
>> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
>>
>>>
>>>>
>>>>>
>>>>> In this case, it's useful to rewalk the page-table with the specific
>>>>> range to get the number of block mapping.
>>>>>
>>>>>>
>>>>>>> +	split_pgtables_idx = 0;
>>>>>>> +	split_pgtables_count = 0;
>>>>>>> +
>>>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>>>>>> +						    &collect_to_split_ops,
>>>>>>> +						    NULL, NULL);
>>>>>>> +	if (!ret)
>>>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>>>>>> +							    &collect_to_split_ops,
>>>>>>> +							    NULL, NULL);
>>>>>>> +	if (ret || !split_pgtables_count)
>>>>>>> +		goto error;
> 
> Just noticed this, but why do we check '!split_pgtables_count' here?
> if the page-table is already somehow mapped at page granularity, that
> doesn't necessarily sound like a fatal error to me.
> 
>>>>>>> +
>>>>>>> +	ret = -ENOMEM;
>>>>>>> +
>>>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>>>>>> +				  GFP_KERNEL | __GFP_ZERO);
>>>>>>> +	if (!split_pgtables)
>>>>>>> +		goto error;
>>>>>>> +
>>>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>>>>>> +		if (!split_pgtables[i])
>>>>>>> +			goto error;
>>>>>>
>>>>>> This looks potentially expensive on the boot path and only gets worse as
>>>>>> the amount of memory grows. Maybe we should predicate this preallocation
>>>>>> on preempt-rt?
>>>>>
>>>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>>>>
>>>> I guess I'm missing something obvious but I don't understand the problem here...
>>>> We are only deferring the allocation of all these pgtables, so the cost is
>>>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
>>>> earlier, we would have had to allocate all these pgtables earlier.
>>>>
>>>> Another way to look at it is that we are still allocating the same number of
>>>> pgtables in the existing fallback path, it's just that we are doing it inside
>>>> the stop_machine().
>>>>
>>>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
>>>> with significantly less testing...
>>>
>>> IIUC, Will's mention is additional memory allocation for
>>> "split_pgtables" where saved "pre-allocate" page tables.
>>> As the memory increase, definitely this size would increase the cost.
>>
>> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
>> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
> 
> Right, it was the page-table pages I was worried about not the array of
> pointers.
> 
>> I suspect we have both misunderstood Will's point...
> 
> I probably just got confused by linear_map_free_split_pgtables() as it
> has logic to free unused page-table pages between 'split_pgtables_idx'
> and 'split_pgtables_count', implying that we can over-allocate.
> 
> If that is only needed for the error path in
> linear_map_prealloc_split_pgtables(), then perhaps that part should be
> inlined to deal with the case where we fail to allocate part way through.

I was originally concerned [1] that there could be a race where another CPU
caused the normal splitting machinery to kick in after this cpu determined the
number of required page tables, so there could be some left over in that case.

On reflection, I guess (hope) that's not possible because we've determined that
some CPUs don't support BBML2. I'm guessing the secondaries haven't been
released to do general work yet?

In which case, I agree, this could be simplified and we could just assert that
all pre-allocated pages get used up if there is no error?

[1] https://lore.kernel.org/all/73ced1db-a2e2-49ea-927e-9fc4a30e771e@arm.com/

> 
> Will

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Ryan,

> On 20/01/2026 15:53, Will Deacon wrote:
> > On Tue, Jan 20, 2026 at 10:40:30AM +0000, Ryan Roberts wrote:
> >> On 20/01/2026 09:29, Yeoreum Yun wrote:
> >>> Hi Ryan
> >>>> On 19/01/2026 21:24, Yeoreum Yun wrote:
> >>>>> Hi Will,
> >>>>>
> >>>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> >>>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
> >>>>>>> +{
> >>>>>>> +	int ret, i;
> >>>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> >>>>>>> +	unsigned long lend = PAGE_END;
> >>>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> >>>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> >>>>>>> +
> >>>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
> >>>>>>> +		.pud_entry	= collect_to_split_pud_entry,
> >>>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
> >>>>>>> +	};
> >>>>>>
> >>>>>> Why do we need to rewalk the page-table here instead of collating the
> >>>>>> number of block mappings we put down when creating the linear map in
> >>>>>> the first place?linear_map_maybe_split_to_ptes(
> >>>>
> >>>> That's a good point; perhaps we can reuse the counters that this series introduces?
> >>>>
> >>>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> >>>>
> >>>>>
> >>>>> First, linear alias of the [_text, __init_begin) is not a target for
> >>>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
> >>>>> that both checks an address range and counts to get the number of block mappings.
> >>>>>
> >>>>> Second, for a future feature,
> >>>>> I hope to add some code to split "specfic" area to be spilt e.x)
> >>>>> to set a specific pkey for specific area.
> >>>>
> >>>> Could you give more detail on this? My working assumption is that either the
> >>>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> >>>> linear map. If it does, we already have logic to split parts of the linear map
> >>>> when needed.
> >>>
> >>> This is not for a linear mapping case. but for a "kernel text area".
> >>> As a draft, I want to mark some of kernel code can executable
> >>> both kernel and eBPF program.
> >>> (I'm trying to make eBPF program non-executable kernel code directly
> >>> with POE feature).
> >>> For this "executable area" both of kernel and eBPF program
> >>> -- typical example is exception entry, It need to split that specific
> >>> range and mark them with special POE index.
> >>
> >> Ahh yes, I recall you mentioning this a while back (although I confess all the
> >> deatils have fallen out of my head). You'd need to make sure you're definitely
> >> not splitting an area of text that the secondary CPUs are executing while they
> >> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
> >>
> >>>
> >>>>
> >>>>>
> >>>>> In this case, it's useful to rewalk the page-table with the specific
> >>>>> range to get the number of block mapping.
> >>>>>
> >>>>>>
> >>>>>>> +	split_pgtables_idx = 0;
> >>>>>>> +	split_pgtables_count = 0;
> >>>>>>> +
> >>>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> >>>>>>> +						    &collect_to_split_ops,
> >>>>>>> +						    NULL, NULL);
> >>>>>>> +	if (!ret)
> >>>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> >>>>>>> +							    &collect_to_split_ops,
> >>>>>>> +							    NULL, NULL);
> >>>>>>> +	if (ret || !split_pgtables_count)
> >>>>>>> +		goto error;
> >
> > Just noticed this, but why do we check '!split_pgtables_count' here?
> > if the page-table is already somehow mapped at page granularity, that
> > doesn't necessarily sound like a fatal error to me.
> >
> >>>>>>> +
> >>>>>>> +	ret = -ENOMEM;
> >>>>>>> +
> >>>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> >>>>>>> +				  GFP_KERNEL | __GFP_ZERO);
> >>>>>>> +	if (!split_pgtables)
> >>>>>>> +		goto error;
> >>>>>>> +
> >>>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
> >>>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> >>>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> >>>>>>> +		if (!split_pgtables[i])
> >>>>>>> +			goto error;
> >>>>>>
> >>>>>> This looks potentially expensive on the boot path and only gets worse as
> >>>>>> the amount of memory grows. Maybe we should predicate this preallocation
> >>>>>> on preempt-rt?
> >>>>>
> >>>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> >>>>
> >>>> I guess I'm missing something obvious but I don't understand the problem here...
> >>>> We are only deferring the allocation of all these pgtables, so the cost is
> >>>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> >>>> earlier, we would have had to allocate all these pgtables earlier.
> >>>>
> >>>> Another way to look at it is that we are still allocating the same number of
> >>>> pgtables in the existing fallback path, it's just that we are doing it inside
> >>>> the stop_machine().
> >>>>
> >>>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> >>>> with significantly less testing...
> >>>
> >>> IIUC, Will's mention is additional memory allocation for
> >>> "split_pgtables" where saved "pre-allocate" page tables.
> >>> As the memory increase, definitely this size would increase the cost.
> >>
> >> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
> >> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
> >
> > Right, it was the page-table pages I was worried about not the array of
> > pointers.
> >
> >> I suspect we have both misunderstood Will's point...
> >
> > I probably just got confused by linear_map_free_split_pgtables() as it
> > has logic to free unused page-table pages between 'split_pgtables_idx'
> > and 'split_pgtables_count', implying that we can over-allocate.
> >
> > If that is only needed for the error path in
> > linear_map_prealloc_split_pgtables(), then perhaps that part should be
> > inlined to deal with the case where we fail to allocate part way through.
>
> I was originally concerned [1] that there could be a race where another CPU
> caused the normal splitting machinery to kick in after this cpu determined the
> number of required page tables, so there could be some left over in that case.
>
> On reflection, I guess (hope) that's not possible because we've determined that
> some CPUs don't support BBML2. I'm guessing the secondaries haven't been
> released to do general work yet?

I don't think so, since the linear_map_maybe_split_to_ptes() called
in smp_cpus_done() but in here, secondary cpus already on and
it seems schedulable.

That's why although, This is unlikely, after collecting the number of
splitiing by other cpu have a possibility to *split* which was counted
and at that time I agreed for your comments because of this *low
possiblity*.

>
> In which case, I agree, this could be simplified and we could just assert that
> all pre-allocated pages get used up if there is no error?
>
> [1] https://lore.kernel.org/all/73ced1db-a2e2-49ea-927e-9fc4a30e771e@arm.com/

So with above reason, I still think it need to sustain the free
unused pagetable.

Am I missing something?

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

On 20/01/2026 16:31, Yeoreum Yun wrote:
> Hi Ryan,
> 
>> On 20/01/2026 15:53, Will Deacon wrote:
>>> On Tue, Jan 20, 2026 at 10:40:30AM +0000, Ryan Roberts wrote:
>>>> On 20/01/2026 09:29, Yeoreum Yun wrote:
>>>>> Hi Ryan
>>>>>> On 19/01/2026 21:24, Yeoreum Yun wrote:
>>>>>>> Hi Will,
>>>>>>>
>>>>>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>>>>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>>>>>>>> +{
>>>>>>>>> +	int ret, i;
>>>>>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>>>>>>>> +	unsigned long lend = PAGE_END;
>>>>>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>>>>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>>>>>>>> +
>>>>>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>>>>>>>> +		.pud_entry	= collect_to_split_pud_entry,
>>>>>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>>>>>>>> +	};
>>>>>>>>
>>>>>>>> Why do we need to rewalk the page-table here instead of collating the
>>>>>>>> number of block mappings we put down when creating the linear map in
>>>>>>>> the first place?linear_map_maybe_split_to_ptes(
>>>>>>
>>>>>> That's a good point; perhaps we can reuse the counters that this series introduces?
>>>>>>
>>>>>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>>>>>>
>>>>>>>
>>>>>>> First, linear alias of the [_text, __init_begin) is not a target for
>>>>>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
>>>>>>> that both checks an address range and counts to get the number of block mappings.
>>>>>>>
>>>>>>> Second, for a future feature,
>>>>>>> I hope to add some code to split "specfic" area to be spilt e.x)
>>>>>>> to set a specific pkey for specific area.
>>>>>>
>>>>>> Could you give more detail on this? My working assumption is that either the
>>>>>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
>>>>>> linear map. If it does, we already have logic to split parts of the linear map
>>>>>> when needed.
>>>>>
>>>>> This is not for a linear mapping case. but for a "kernel text area".
>>>>> As a draft, I want to mark some of kernel code can executable
>>>>> both kernel and eBPF program.
>>>>> (I'm trying to make eBPF program non-executable kernel code directly
>>>>> with POE feature).
>>>>> For this "executable area" both of kernel and eBPF program
>>>>> -- typical example is exception entry, It need to split that specific
>>>>> range and mark them with special POE index.
>>>>
>>>> Ahh yes, I recall you mentioning this a while back (although I confess all the
>>>> deatils have fallen out of my head). You'd need to make sure you're definitely
>>>> not splitting an area of text that the secondary CPUs are executing while they
>>>> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> In this case, it's useful to rewalk the page-table with the specific
>>>>>>> range to get the number of block mapping.
>>>>>>>
>>>>>>>>
>>>>>>>>> +	split_pgtables_idx = 0;
>>>>>>>>> +	split_pgtables_count = 0;
>>>>>>>>> +
>>>>>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>>>>>>>> +						    &collect_to_split_ops,
>>>>>>>>> +						    NULL, NULL);
>>>>>>>>> +	if (!ret)
>>>>>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>>>>>>>> +							    &collect_to_split_ops,
>>>>>>>>> +							    NULL, NULL);
>>>>>>>>> +	if (ret || !split_pgtables_count)
>>>>>>>>> +		goto error;
>>>
>>> Just noticed this, but why do we check '!split_pgtables_count' here?
>>> if the page-table is already somehow mapped at page granularity, that
>>> doesn't necessarily sound like a fatal error to me.
>>>
>>>>>>>>> +
>>>>>>>>> +	ret = -ENOMEM;
>>>>>>>>> +
>>>>>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>>>>>>>> +				  GFP_KERNEL | __GFP_ZERO);
>>>>>>>>> +	if (!split_pgtables)
>>>>>>>>> +		goto error;
>>>>>>>>> +
>>>>>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>>>>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>>>>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>>>>>>>> +		if (!split_pgtables[i])
>>>>>>>>> +			goto error;
>>>>>>>>
>>>>>>>> This looks potentially expensive on the boot path and only gets worse as
>>>>>>>> the amount of memory grows. Maybe we should predicate this preallocation
>>>>>>>> on preempt-rt?
>>>>>>>
>>>>>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>>>>>>
>>>>>> I guess I'm missing something obvious but I don't understand the problem here...
>>>>>> We are only deferring the allocation of all these pgtables, so the cost is
>>>>>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
>>>>>> earlier, we would have had to allocate all these pgtables earlier.
>>>>>>
>>>>>> Another way to look at it is that we are still allocating the same number of
>>>>>> pgtables in the existing fallback path, it's just that we are doing it inside
>>>>>> the stop_machine().
>>>>>>
>>>>>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
>>>>>> with significantly less testing...
>>>>>
>>>>> IIUC, Will's mention is additional memory allocation for
>>>>> "split_pgtables" where saved "pre-allocate" page tables.
>>>>> As the memory increase, definitely this size would increase the cost.
>>>>
>>>> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
>>>> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
>>>
>>> Right, it was the page-table pages I was worried about not the array of
>>> pointers.
>>>
>>>> I suspect we have both misunderstood Will's point...
>>>
>>> I probably just got confused by linear_map_free_split_pgtables() as it
>>> has logic to free unused page-table pages between 'split_pgtables_idx'
>>> and 'split_pgtables_count', implying that we can over-allocate.
>>>
>>> If that is only needed for the error path in
>>> linear_map_prealloc_split_pgtables(), then perhaps that part should be
>>> inlined to deal with the case where we fail to allocate part way through.
>>
>> I was originally concerned [1] that there could be a race where another CPU
>> caused the normal splitting machinery to kick in after this cpu determined the
>> number of required page tables, so there could be some left over in that case.
>>
>> On reflection, I guess (hope) that's not possible because we've determined that
>> some CPUs don't support BBML2. I'm guessing the secondaries haven't been
>> released to do general work yet?
> 
> I don't think so, since the linear_map_maybe_split_to_ptes() called
> in smp_cpus_done() but in here, secondary cpus already on and
> it seems schedulable.
> 
> That's why although, This is unlikely, after collecting the number of
> splitiing by other cpu have a possibility to *split* which was counted
> and at that time I agreed for your comments because of this *low
> possiblity*.
> 
>>
>> In which case, I agree, this could be simplified and we could just assert that
>> all pre-allocated pages get used up if there is no error?
>>
>> [1] https://lore.kernel.org/all/73ced1db-a2e2-49ea-927e-9fc4a30e771e@arm.com/
> 
> So with above reason, I still think it need to sustain the free
> unused pagetable.
> 
> Am I missing something?

My concern is that if a secondary CPU can race and cause a split, that is
unsound because we have determined that although the primary CPU supports BBML2,
at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.

I just had a brief chat with Rutland, and he agrees that this _could_ be a
problem. Basically there is a window between onlining the secondary cpus and
entering the stop_machine() where one of those cpus _could_ end up doing
something that causes us to split the linear map.

I'm not immediately sure how to solve that.

> 
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

On Tue, Jan 20, 2026 at 05:35:50PM +0000, Ryan Roberts wrote:
> On 20/01/2026 16:31, Yeoreum Yun wrote:
> > Hi Ryan,
> >
> >> On 20/01/2026 15:53, Will Deacon wrote:
> >>> On Tue, Jan 20, 2026 at 10:40:30AM +0000, Ryan Roberts wrote:
> >>>> On 20/01/2026 09:29, Yeoreum Yun wrote:
> >>>>> Hi Ryan
> >>>>>> On 19/01/2026 21:24, Yeoreum Yun wrote:
> >>>>>>> Hi Will,
> >>>>>>>
> >>>>>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> >>>>>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
> >>>>>>>>> +{
> >>>>>>>>> +	int ret, i;
> >>>>>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> >>>>>>>>> +	unsigned long lend = PAGE_END;
> >>>>>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> >>>>>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> >>>>>>>>> +
> >>>>>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
> >>>>>>>>> +		.pud_entry	= collect_to_split_pud_entry,
> >>>>>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
> >>>>>>>>> +	};
> >>>>>>>>
> >>>>>>>> Why do we need to rewalk the page-table here instead of collating the
> >>>>>>>> number of block mappings we put down when creating the linear map in
> >>>>>>>> the first place?linear_map_maybe_split_to_ptes(
> >>>>>>
> >>>>>> That's a good point; perhaps we can reuse the counters that this series introduces?
> >>>>>>
> >>>>>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> >>>>>>
> >>>>>>>
> >>>>>>> First, linear alias of the [_text, __init_begin) is not a target for
> >>>>>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
> >>>>>>> that both checks an address range and counts to get the number of block mappings.
> >>>>>>>
> >>>>>>> Second, for a future feature,
> >>>>>>> I hope to add some code to split "specfic" area to be spilt e.x)
> >>>>>>> to set a specific pkey for specific area.
> >>>>>>
> >>>>>> Could you give more detail on this? My working assumption is that either the
> >>>>>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> >>>>>> linear map. If it does, we already have logic to split parts of the linear map
> >>>>>> when needed.
> >>>>>
> >>>>> This is not for a linear mapping case. but for a "kernel text area".
> >>>>> As a draft, I want to mark some of kernel code can executable
> >>>>> both kernel and eBPF program.
> >>>>> (I'm trying to make eBPF program non-executable kernel code directly
> >>>>> with POE feature).
> >>>>> For this "executable area" both of kernel and eBPF program
> >>>>> -- typical example is exception entry, It need to split that specific
> >>>>> range and mark them with special POE index.
> >>>>
> >>>> Ahh yes, I recall you mentioning this a while back (although I confess all the
> >>>> deatils have fallen out of my head). You'd need to make sure you're definitely
> >>>> not splitting an area of text that the secondary CPUs are executing while they
> >>>> are being held in the pen, since at least one of those CPUs doesn't support BBML2.
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> In this case, it's useful to rewalk the page-table with the specific
> >>>>>>> range to get the number of block mapping.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> +	split_pgtables_idx = 0;
> >>>>>>>>> +	split_pgtables_count = 0;
> >>>>>>>>> +
> >>>>>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> >>>>>>>>> +						    &collect_to_split_ops,
> >>>>>>>>> +						    NULL, NULL);
> >>>>>>>>> +	if (!ret)
> >>>>>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> >>>>>>>>> +							    &collect_to_split_ops,
> >>>>>>>>> +							    NULL, NULL);
> >>>>>>>>> +	if (ret || !split_pgtables_count)
> >>>>>>>>> +		goto error;
> >>>
> >>> Just noticed this, but why do we check '!split_pgtables_count' here?
> >>> if the page-table is already somehow mapped at page granularity, that
> >>> doesn't necessarily sound like a fatal error to me.
> >>>
> >>>>>>>>> +
> >>>>>>>>> +	ret = -ENOMEM;
> >>>>>>>>> +
> >>>>>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> >>>>>>>>> +				  GFP_KERNEL | __GFP_ZERO);
> >>>>>>>>> +	if (!split_pgtables)
> >>>>>>>>> +		goto error;
> >>>>>>>>> +
> >>>>>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
> >>>>>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> >>>>>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> >>>>>>>>> +		if (!split_pgtables[i])
> >>>>>>>>> +			goto error;
> >>>>>>>>
> >>>>>>>> This looks potentially expensive on the boot path and only gets worse as
> >>>>>>>> the amount of memory grows. Maybe we should predicate this preallocation
> >>>>>>>> on preempt-rt?
> >>>>>>>
> >>>>>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> >>>>>>
> >>>>>> I guess I'm missing something obvious but I don't understand the problem here...
> >>>>>> We are only deferring the allocation of all these pgtables, so the cost is
> >>>>>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
> >>>>>> earlier, we would have had to allocate all these pgtables earlier.
> >>>>>>
> >>>>>> Another way to look at it is that we are still allocating the same number of
> >>>>>> pgtables in the existing fallback path, it's just that we are doing it inside
> >>>>>> the stop_machine().
> >>>>>>
> >>>>>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> >>>>>> with significantly less testing...
> >>>>>
> >>>>> IIUC, Will's mention is additional memory allocation for
> >>>>> "split_pgtables" where saved "pre-allocate" page tables.
> >>>>> As the memory increase, definitely this size would increase the cost.
> >>>>
> >>>> Err, so you're referring to the extra kvmalloc()? I don't think that's a big
> >>>> deal is it? you get 512 pointers per page. So the amortized cost is 1/512= 0.2%?
> >>>
> >>> Right, it was the page-table pages I was worried about not the array of
> >>> pointers.
> >>>
> >>>> I suspect we have both misunderstood Will's point...
> >>>
> >>> I probably just got confused by linear_map_free_split_pgtables() as it
> >>> has logic to free unused page-table pages between 'split_pgtables_idx'
> >>> and 'split_pgtables_count', implying that we can over-allocate.
> >>>
> >>> If that is only needed for the error path in
> >>> linear_map_prealloc_split_pgtables(), then perhaps that part should be
> >>> inlined to deal with the case where we fail to allocate part way through.
> >>
> >> I was originally concerned [1] that there could be a race where another CPU
> >> caused the normal splitting machinery to kick in after this cpu determined the
> >> number of required page tables, so there could be some left over in that case.
> >>
> >> On reflection, I guess (hope) that's not possible because we've determined that
> >> some CPUs don't support BBML2. I'm guessing the secondaries haven't been
> >> released to do general work yet?
> >
> > I don't think so, since the linear_map_maybe_split_to_ptes() called
> > in smp_cpus_done() but in here, secondary cpus already on and
> > it seems schedulable.
> >
> > That's why although, This is unlikely, after collecting the number of
> > splitiing by other cpu have a possibility to *split* which was counted
> > and at that time I agreed for your comments because of this *low
> > possiblity*.
> >
> >>
> >> In which case, I agree, this could be simplified and we could just assert that
> >> all pre-allocated pages get used up if there is no error?
> >>
> >> [1] https://lore.kernel.org/all/73ced1db-a2e2-49ea-927e-9fc4a30e771e@arm.com/
> >
> > So with above reason, I still think it need to sustain the free
> > unused pagetable.
> >
> > Am I missing something?
>
> My concern is that if a secondary CPU can race and cause a split, that is
> unsound because we have determined that although the primary CPU supports BBML2,
> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
>
> I just had a brief chat with Rutland, and he agrees that this _could_ be a
> problem. Basically there is a window between onlining the secondary cpus and
> entering the stop_machine() where one of those cpus _could_ end up doing
> something that causes us to split the linear map.

Regardless of BBML2, does it means it would be a problem call
set_memory_xxx() API during this windows?

For example,

CPU0 (boot)                                CPU1 (secondary)
linear_map_maybe_split_to_ptes()
  collect the number of pagetable
                                           set_memory_xxx()
					      split the specific linear region

  preallocate() and spliting().

TBH, I'm not sure why this scenario could be a problem?

> > --
> > Sincerely,
> > Yeoreum Yun
>

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yang Shi]

>> My concern is that if a secondary CPU can race and cause a split, that is
>> unsound because we have determined that although the primary CPU supports BBML2,
>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
>>
>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
>> problem. Basically there is a window between onlining the secondary cpus and
>> entering the stop_machine() where one of those cpus _could_ end up doing
>> something that causes us to split the linear map.

If I remember correctly, split_kernel_leaf_mapping() does call 
system_supports_bbml2_noabort() before doing real split. So we basically 
should fall into two categories:

1. bbml2_noabort is supported on all cpus. Everything is fine.
2. bbml2_noabort is not supported on all cpus. 
split_kernel_leaf_mapping() just returns 0. Kernel doesn't split page 
table, so there won't be TLB conflict issue. But the following page prot 
update may see unexpected block mapping, then a   WARN  will be raised 
and it will return -EINVAL. So the worst case is the caller will fail 
(IIRC all the callers of set_memory_*() handle the failure), and we can 
know who is trying to change linear mapping before the linear mapping 
gets                    finalized. AFAICT I haven't seen such WARN yet.

>>
>> I'm not immediately sure how to solve that.

Do we need some synchronization mechanism? If the linear mapping is not 
finalized yet, split_kernel_leaf_mapping() will spin. For example, 
something like this off the top of my head,

DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);

Once the linear mapping is finalized, we can call 
static_branch_enable(&linear_mapping_finalized);

In split_kernel_leaf_mapping(), we can just do:

retry:
     if (!static_branch_likely(&linear_mapping_finalized))
         goto retry;


There may be better way to handle it. But this case should be very 
unlikely IMHO. It sounds crazy to have such complicated kernel threads 
run so early. I'm not sure whether we should pay immediate attention to 
it or not.

Thanks,
Yang

>>
>> --
>> Sincerely,
>> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

> > > My concern is that if a secondary CPU can race and cause a split, that is
> > > unsound because we have determined that although the primary CPU supports BBML2,
> > > at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
> > >
> > > I just had a brief chat with Rutland, and he agrees that this _could_ be a
> > > problem. Basically there is a window between onlining the secondary cpus and
> > > entering the stop_machine() where one of those cpus _could_ end up doing
> > > something that causes us to split the linear map.
>
> If I remember correctly, split_kernel_leaf_mapping() does call
> system_supports_bbml2_noabort() before doing real split. So we basically
> should fall into two categories:
>
> 1. bbml2_noabort is supported on all cpus. Everything is fine.
> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
> just returns 0. Kernel doesn't split page table, so there won't be TLB
> conflict issue. But the following page prot update may see unexpected block
> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
> worst case is the caller will fail (IIRC all the callers of set_memory_*()
> handle the failure), and we can know who is trying to change linear mapping
> before the linear mapping gets                    finalized. AFAICT I
> haven't seen such WARN yet.

Thanks for the great detail :)
I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().

>
> > >
> > > I'm not immediately sure how to solve that.
>
> Do we need some synchronization mechanism? If the linear mapping is not
> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
> like this off the top of my head,
>
> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
>
> Once the linear mapping is finalized, we can call
> static_branch_enable(&linear_mapping_finalized);
>
> In split_kernel_leaf_mapping(), we can just do:
>
> retry:
>     if (!static_branch_likely(&linear_mapping_finalized))
>         goto retry;
>
>
> There may be better way to handle it. But this case should be very unlikely
> IMHO. It sounds crazy to have such complicated kernel threads run so early.
> I'm not sure whether we should pay immediate attention to it or not.

Thinking about it again, I’m not sure whether
it is acceptable to use a sleepable synchronization mechanism at this stage,
like split_kernel_leaf_mapping() does with mutex_lock()
(even though it may be technically possible).
It also feels odd that this function can be called at this point in time.

If this is indeed considered problematic,
I think it would be better to simply return -EINVAL immediately
when linear_mapping_finalized has not yet been completed.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

On 21/01/2026 08:32, Yeoreum Yun wrote:
>>>> My concern is that if a secondary CPU can race and cause a split, that is
>>>> unsound because we have determined that although the primary CPU supports BBML2,
>>>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
>>>>
>>>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
>>>> problem. Basically there is a window between onlining the secondary cpus and
>>>> entering the stop_machine() where one of those cpus _could_ end up doing
>>>> something that causes us to split the linear map.
>>
>> If I remember correctly, split_kernel_leaf_mapping() does call
>> system_supports_bbml2_noabort() before doing real split. So we basically
>> should fall into two categories:
>>
>> 1. bbml2_noabort is supported on all cpus. Everything is fine.
>> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
>> just returns 0. Kernel doesn't split page table, so there won't be TLB
>> conflict issue. But the following page prot update may see unexpected block
>> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
>> worst case is the caller will fail (IIRC all the callers of set_memory_*()
>> handle the failure), and we can know who is trying to change linear mapping
>> before the linear mapping gets                    finalized. AFAICT I
>> haven't seen such WARN yet.

Ahh good point! So this isn't quite as terrible as I was thinking.

> 
> Thanks for the great detail :)
> I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
> 
>>
>>>>
>>>> I'm not immediately sure how to solve that.
>>
>> Do we need some synchronization mechanism? If the linear mapping is not
>> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
>> like this off the top of my head,
>>
>> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
>>
>> Once the linear mapping is finalized, we can call
>> static_branch_enable(&linear_mapping_finalized);
>>
>> In split_kernel_leaf_mapping(), we can just do:
>>
>> retry:
>>     if (!static_branch_likely(&linear_mapping_finalized))
>>         goto retry;
>>

Yuck... But I guess it might work as long as the primary thread never does
anything that would cause an attempt to split; otherwise we have a deadlock.

>>
>> There may be better way to handle it. But this case should be very unlikely
>> IMHO. It sounds crazy to have such complicated kernel threads run so early.
>> I'm not sure whether we should pay immediate attention to it or not.

I think we need to figure out if this is actually possible. We bring up the
secondary cpus, set system caps and finalize the linear map in smp_init().
That's called from kernel_init_freeable() which is called from kernel_init(),
which is invoked as a thread pinned to the boot cpu.

sched_init_smp() is called after smp_init() (i.e. after the linear map is
finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
other than the idle thread will run on any secondaries until after
sched_init_smp() is called? (I'd be greatful if anyone can confirm that).

Rutland suggested that it's probably too early for any PM type stuff to be
running in the idle loop, so based on all of that, perhaps this is not a problem
after all and there is basically zero chance of a secondary cpu doing anything
that could cause a linear map split during this window?

I'm inclined to leave this as is for now.

Thanks,
Ryan

> 
> Thinking about it again, I’m not sure whether
> it is acceptable to use a sleepable synchronization mechanism at this stage,
> like split_kernel_leaf_mapping() does with mutex_lock()
> (even though it may be technically possible).
> It also feels odd that this function can be called at this point in time.
> 
> If this is indeed considered problematic,
> I think it would be better to simply return -EINVAL immediately
> when linear_mapping_finalized has not yet been completed.
> 
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

On Wed, Jan 21, 2026 at 10:20:52AM +0000, Ryan Roberts wrote:
> On 21/01/2026 08:32, Yeoreum Yun wrote:
> >>>> My concern is that if a secondary CPU can race and cause a split, that is
> >>>> unsound because we have determined that although the primary CPU supports BBML2,
> >>>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
> >>>>
> >>>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
> >>>> problem. Basically there is a window between onlining the secondary cpus and
> >>>> entering the stop_machine() where one of those cpus _could_ end up doing
> >>>> something that causes us to split the linear map.
> >>
> >> If I remember correctly, split_kernel_leaf_mapping() does call
> >> system_supports_bbml2_noabort() before doing real split. So we basically
> >> should fall into two categories:
> >>
> >> 1. bbml2_noabort is supported on all cpus. Everything is fine.
> >> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
> >> just returns 0. Kernel doesn't split page table, so there won't be TLB
> >> conflict issue. But the following page prot update may see unexpected block
> >> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
> >> worst case is the caller will fail (IIRC all the callers of set_memory_*()
> >> handle the failure), and we can know who is trying to change linear mapping
> >> before the linear mapping gets                    finalized. AFAICT I
> >> haven't seen such WARN yet.
>
> Ahh good point! So this isn't quite as terrible as I was thinking.
>
> >
> > Thanks for the great detail :)
> > I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
> >
> >>
> >>>>
> >>>> I'm not immediately sure how to solve that.
> >>
> >> Do we need some synchronization mechanism? If the linear mapping is not
> >> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
> >> like this off the top of my head,
> >>
> >> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
> >>
> >> Once the linear mapping is finalized, we can call
> >> static_branch_enable(&linear_mapping_finalized);
> >>
> >> In split_kernel_leaf_mapping(), we can just do:
> >>
> >> retry:
> >>     if (!static_branch_likely(&linear_mapping_finalized))
> >>         goto retry;
> >>
>
> Yuck... But I guess it might work as long as the primary thread never does
> anything that would cause an attempt to split; otherwise we have a deadlock.
>
> >>
> >> There may be better way to handle it. But this case should be very unlikely
> >> IMHO. It sounds crazy to have such complicated kernel threads run so early.
> >> I'm not sure whether we should pay immediate attention to it or not.
>
> I think we need to figure out if this is actually possible. We bring up the
> secondary cpus, set system caps and finalize the linear map in smp_init().
> That's called from kernel_init_freeable() which is called from kernel_init(),
> which is invoked as a thread pinned to the boot cpu.
>
> sched_init_smp() is called after smp_init() (i.e. after the linear map is
> finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
> other than the idle thread will run on any secondaries until after
> sched_init_smp() is called? (I'd be greatful if anyone can confirm that).
>
> Rutland suggested that it's probably too early for any PM type stuff to be
> running in the idle loop, so based on all of that, perhaps this is not a problem
> after all and there is basically zero chance of a secondary cpu doing anything
> that could cause a linear map split during this window?
>
> I'm inclined to leave this as is for now.

IIUC, since it before the sched_domain creation yet,
the wake_up_new_task()'s cpu selection via select_task_rq_fair()
would be always the same for prev_cpu. So I agree with you
this case would be a zero chance of a scondary cpu doing anything.

>
> Thanks,
> Ryan
>
> >
> > Thinking about it again, I’m not sure whether
> > it is acceptable to use a sleepable synchronization mechanism at this stage,
> > like split_kernel_leaf_mapping() does with mutex_lock()
> > (even though it may be technically possible).
> > It also feels odd that this function can be called at this point in time.
> >
> > If this is indeed considered problematic,
> > I think it would be better to simply return -EINVAL immediately
> > when linear_mapping_finalized has not yet been completed.
> >
> > --
> > Sincerely,
> > Yeoreum Yun
>

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yang Shi]

On 1/21/26 2:20 AM, Ryan Roberts wrote:
> On 21/01/2026 08:32, Yeoreum Yun wrote:
>>>>> My concern is that if a secondary CPU can race and cause a split, that is
>>>>> unsound because we have determined that although the primary CPU supports BBML2,
>>>>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
>>>>>
>>>>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
>>>>> problem. Basically there is a window between onlining the secondary cpus and
>>>>> entering the stop_machine() where one of those cpus _could_ end up doing
>>>>> something that causes us to split the linear map.
>>> If I remember correctly, split_kernel_leaf_mapping() does call
>>> system_supports_bbml2_noabort() before doing real split. So we basically
>>> should fall into two categories:
>>>
>>> 1. bbml2_noabort is supported on all cpus. Everything is fine.
>>> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
>>> just returns 0. Kernel doesn't split page table, so there won't be TLB
>>> conflict issue. But the following page prot update may see unexpected block
>>> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
>>> worst case is the caller will fail (IIRC all the callers of set_memory_*()
>>> handle the failure), and we can know who is trying to change linear mapping
>>> before the linear mapping gets                    finalized. AFAICT I
>>> haven't seen such WARN yet.
> Ahh good point! So this isn't quite as terrible as I was thinking.

Yeah.

>
>> Thanks for the great detail :)
>> I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
>>
>>>>> I'm not immediately sure how to solve that.
>>> Do we need some synchronization mechanism? If the linear mapping is not
>>> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
>>> like this off the top of my head,
>>>
>>> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
>>>
>>> Once the linear mapping is finalized, we can call
>>> static_branch_enable(&linear_mapping_finalized);
>>>
>>> In split_kernel_leaf_mapping(), we can just do:
>>>
>>> retry:
>>>      if (!static_branch_likely(&linear_mapping_finalized))
>>>          goto retry;
>>>
> Yuck... But I guess it might work as long as the primary thread never does
> anything that would cause an attempt to split; otherwise we have a deadlock.
>
>>> There may be better way to handle it. But this case should be very unlikely
>>> IMHO. It sounds crazy to have such complicated kernel threads run so early.
>>> I'm not sure whether we should pay immediate attention to it or not.
> I think we need to figure out if this is actually possible. We bring up the
> secondary cpus, set system caps and finalize the linear map in smp_init().
> That's called from kernel_init_freeable() which is called from kernel_init(),
> which is invoked as a thread pinned to the boot cpu.
>
> sched_init_smp() is called after smp_init() (i.e. after the linear map is
> finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
> other than the idle thread will run on any secondaries until after
> sched_init_smp() is called? (I'd be greatful if anyone can confirm that).
>
> Rutland suggested that it's probably too early for any PM type stuff to be
> running in the idle loop, so based on all of that, perhaps this is not a problem
> after all and there is basically zero chance of a secondary cpu doing anything
> that could cause a linear map split during this window?
>
> I'm inclined to leave this as is for now.

I agree. I don't think this would be a real problem.

Thanks,
Yang

>
> Thanks,
> Ryan
>
>> Thinking about it again, I’m not sure whether
>> it is acceptable to use a sleepable synchronization mechanism at this stage,
>> like split_kernel_leaf_mapping() does with mutex_lock()
>> (even though it may be technically possible).
>> It also feels odd that this function can be called at this point in time.
>>
>> If this is indeed considered problematic,
>> I think it would be better to simply return -EINVAL immediately
>> when linear_mapping_finalized has not yet been completed.
>>
>> --
>> Sincerely,
>> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

On Wed, Jan 21, 2026 at 02:57:28PM -0800, Yang Shi wrote:
>
>
> On 1/21/26 2:20 AM, Ryan Roberts wrote:
> > On 21/01/2026 08:32, Yeoreum Yun wrote:
> > > > > > My concern is that if a secondary CPU can race and cause a split, that is
> > > > > > unsound because we have determined that although the primary CPU supports BBML2,
> > > > > > at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
> > > > > >
> > > > > > I just had a brief chat with Rutland, and he agrees that this _could_ be a
> > > > > > problem. Basically there is a window between onlining the secondary cpus and
> > > > > > entering the stop_machine() where one of those cpus _could_ end up doing
> > > > > > something that causes us to split the linear map.
> > > > If I remember correctly, split_kernel_leaf_mapping() does call
> > > > system_supports_bbml2_noabort() before doing real split. So we basically
> > > > should fall into two categories:
> > > >
> > > > 1. bbml2_noabort is supported on all cpus. Everything is fine.
> > > > 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
> > > > just returns 0. Kernel doesn't split page table, so there won't be TLB
> > > > conflict issue. But the following page prot update may see unexpected block
> > > > mapping, then a   WARN  will be raised and it will return -EINVAL. So the
> > > > worst case is the caller will fail (IIRC all the callers of set_memory_*()
> > > > handle the failure), and we can know who is trying to change linear mapping
> > > > before the linear mapping gets                    finalized. AFAICT I
> > > > haven't seen such WARN yet.
> > Ahh good point! So this isn't quite as terrible as I was thinking.
>
> Yeah.
>
> >
> > > Thanks for the great detail :)
> > > I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
> > >
> > > > > > I'm not immediately sure how to solve that.
> > > > Do we need some synchronization mechanism? If the linear mapping is not
> > > > finalized yet, split_kernel_leaf_mapping() will spin. For example, something
> > > > like this off the top of my head,
> > > >
> > > > DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
> > > >
> > > > Once the linear mapping is finalized, we can call
> > > > static_branch_enable(&linear_mapping_finalized);
> > > >
> > > > In split_kernel_leaf_mapping(), we can just do:
> > > >
> > > > retry:
> > > >      if (!static_branch_likely(&linear_mapping_finalized))
> > > >          goto retry;
> > > >
> > Yuck... But I guess it might work as long as the primary thread never does
> > anything that would cause an attempt to split; otherwise we have a deadlock.
> >
> > > > There may be better way to handle it. But this case should be very unlikely
> > > > IMHO. It sounds crazy to have such complicated kernel threads run so early.
> > > > I'm not sure whether we should pay immediate attention to it or not.
> > I think we need to figure out if this is actually possible. We bring up the
> > secondary cpus, set system caps and finalize the linear map in smp_init().
> > That's called from kernel_init_freeable() which is called from kernel_init(),
> > which is invoked as a thread pinned to the boot cpu.
> >
> > sched_init_smp() is called after smp_init() (i.e. after the linear map is
> > finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
> > other than the idle thread will run on any secondaries until after
> > sched_init_smp() is called? (I'd be greatful if anyone can confirm that).
> >
> > Rutland suggested that it's probably too early for any PM type stuff to be
> > running in the idle loop, so based on all of that, perhaps this is not a problem
> > after all and there is basically zero chance of a secondary cpu doing anything
> > that could cause a linear map split during this window?
> >
> > I'm inclined to leave this as is for now.
>
> I agree. I don't think this would be a real problem.
>
> Thanks,
> Yang

Although partially using GFP_ATOMIC might not be an issue given that
there is no contention at the moment,
technically using a memory allocation API inside stop_machine() is problematic
for PREEMPT_RT, and the relevant page tables should be pre-allocated.

That said, taking a step back (I’m not sure why I was being so stubborn about this),
since the kernel_alias area is mapped using block mappings,
a simple calculation based on your dm_meminfo patch should be sufficient to
determine the number of page tables that need to be pre-allocated for
splitting the linear mapping, without having to walk the page tables again.

So, after your dm_meminfo patch, I plan to respin this patch based on that.

Am I missing anything?

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Ryan Roberts]

>>> I'm inclined to leave this as is for now.
>>
>> I agree. I don't think this would be a real problem.
>>
>> Thanks,
>> Yang
> 
> Although partially using GFP_ATOMIC might not be an issue given that
> there is no contention at the moment,
> technically using a memory allocation API inside stop_machine() is problematic
> for PREEMPT_RT, and the relevant page tables should be pre-allocated.
> 
> That said, taking a step back (I’m not sure why I was being so stubborn about this),
> since the kernel_alias area is mapped using block mappings,
> a simple calculation based on your dm_meminfo patch should be sufficient to
> determine the number of page tables that need to be pre-allocated for
> splitting the linear mapping, without having to walk the page tables again.
> 
> So, after your dm_meminfo patch, I plan to respin this patch based on that.
> 
> Am I missing anything?

Yeoreum and I had an offline chat about all this and I just want to spell out
the conclusion for everybody;

We believe it's impossible for the secondary CPUs to have any scheduled work
during this window, and therefore it's impossible for the split race to occur,
and it's impossible for there to be any contention on the page allocator lock.
All of which means that in practice, there are no bugs here and the code is safe
as is, even for PREEMPT_RT.

That said, allocating memory inside of stop_machine() is a bad smell, so Yeoreum
will rectify this down the track; it's not urgent though.

Thanks,
Ryan

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yang Shi]

On 1/20/26 1:29 AM, Yeoreum Yun wrote:
> Hi Ryan
>> On 19/01/2026 21:24, Yeoreum Yun wrote:
>>> Hi Will,
>>>
>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>>>> +{
>>>>> +	int ret, i;
>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>>>> +	unsigned long lend = PAGE_END;
>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>>>> +
>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>>>> +		.pud_entry	= collect_to_split_pud_entry,
>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>>>> +	};
>>>> Why do we need to rewalk the page-table here instead of collating the
>>>> number of block mappings we put down when creating the linear map in
>>>> the first place?
>> That's a good point; perhaps we can reuse the counters that this series introduces?
>>
>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/

Yeah, good point. It seems feasible to me. The patch can count how many 
PUD/CONT_PMD/PMD mappings, we can calculate how many page table pages 
need to be allocated based on those counters.

>>
>>> First, linear alias of the [_text, __init_begin) is not a target for
>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
>>> that both checks an address range and counts to get the number of block mappings.

IIUC, it should be not that hard to exclude kernel mappings. We know 
kernel_start and kernel_end, so you should be able to maintain a set of 
counters for kernel, then minus them when you do the calculation for how 
many page table pages need to be allocated.

>>>
>>> Second, for a future feature,
>>> I hope to add some code to split "specfic" area to be spilt e.x)
>>> to set a specific pkey for specific area.
>> Could you give more detail on this? My working assumption is that either the
>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
>> linear map. If it does, we already have logic to split parts of the linear map
>> when needed.
> This is not for a linear mapping case. but for a "kernel text area".
> As a draft, I want to mark some of kernel code can executable
> both kernel and eBPF program.
> (I'm trying to make eBPF program non-executable kernel code directly
> with POE feature).
> For this "executable area" both of kernel and eBPF program
> -- typical example is exception entry, It need to split that specific
> range and mark them with special POE index.

IIUC, you want to change POE attributes for some kernel area (mainly in 
vmalloc address space). It sounds like you can do something like 
set_memory_rox(), but just split vmalloc address mapping instead of 
linear mapping. Or you need preallocate page table pages in this case? 
Anyway we can have more simple way to count block mappings for splitting 
linear mapping, it seems not necessary to re-walk page table again IMHO.

Thanks,
Yang

>
>>> In this case, it's useful to rewalk the page-table with the specific
>>> range to get the number of block mapping.
>>>
>>>>> +	split_pgtables_idx = 0;
>>>>> +	split_pgtables_count = 0;
>>>>> +
>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>>>> +						    &collect_to_split_ops,
>>>>> +						    NULL, NULL);
>>>>> +	if (!ret)
>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>>>> +							    &collect_to_split_ops,
>>>>> +							    NULL, NULL);
>>>>> +	if (ret || !split_pgtables_count)
>>>>> +		goto error;
>>>>> +
>>>>> +	ret = -ENOMEM;
>>>>> +
>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>>>> +				  GFP_KERNEL | __GFP_ZERO);
>>>>> +	if (!split_pgtables)
>>>>> +		goto error;
>>>>> +
>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>>>> +		if (!split_pgtables[i])
>>>>> +			goto error;
>>>> This looks potentially expensive on the boot path and only gets worse as
>>>> the amount of memory grows. Maybe we should predicate this preallocation
>>>> on preempt-rt?
>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>> I guess I'm missing something obvious but I don't understand the problem here...
>> We are only deferring the allocation of all these pgtables, so the cost is
>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
>> earlier, we would have had to allocate all these pgtables earlier.
>>
>> Another way to look at it is that we are still allocating the same number of
>> pgtables in the existing fallback path, it's just that we are doing it inside
>> the stop_machine().
>>
>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
>> with significantly less testing...
> IIUC, Will's mention is additional memory allocation for
> "split_pgtables" where saved "pre-allocate" page tables.
> As the memory increase, definitely this size would increase the cost.
>
> And this cost need not to burden for !PREEMPT_RT since
> it can use memory allocation in stop_machine() with GFP_ATOMIC.
>
> But I also agree in the aspect that if that cost not much of huge,
> It's also convincing and additionally, as I mentioned in another thread,
> It would be good not to give a hallucination GFP_ATOMIC is fine for
> everywhere even in the PREEMPT_RT.
>
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Yang,
>
>
> On 1/20/26 1:29 AM, Yeoreum Yun wrote:
> > Hi Ryan
> > > On 19/01/2026 21:24, Yeoreum Yun wrote:
> > > > Hi Will,
> > > >
> > > > > On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> > > > > > +static int __init linear_map_prealloc_split_pgtables(void)
> > > > > > +{
> > > > > > +	int ret, i;
> > > > > > +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> > > > > > +	unsigned long lend = PAGE_END;
> > > > > > +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> > > > > > +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> > > > > > +
> > > > > > +	const struct mm_walk_ops collect_to_split_ops = {
> > > > > > +		.pud_entry	= collect_to_split_pud_entry,
> > > > > > +		.pmd_entry	= collect_to_split_pmd_entry
> > > > > > +	};
> > > > > Why do we need to rewalk the page-table here instead of collating the
> > > > > number of block mappings we put down when creating the linear map in
> > > > > the first place?
> > > That's a good point; perhaps we can reuse the counters that this series introduces?
> > >
> > > https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>
> Yeah, good point. It seems feasible to me. The patch can count how many
> PUD/CONT_PMD/PMD mappings, we can calculate how many page table pages need
> to be allocated based on those counters.
>
> > >
> > > > First, linear alias of the [_text, __init_begin) is not a target for
> > > > the split and it also seems strange to me to add code inside alloc_init_XXX()
> > > > that both checks an address range and counts to get the number of block mappings.
>
> IIUC, it should be not that hard to exclude kernel mappings. We know
> kernel_start and kernel_end, so you should be able to maintain a set of
> counters for kernel, then minus them when you do the calculation for how
> many page table pages need to be allocated.

As you said, this is not difficult. However, what I meant was that
this collection would be done in alloc_init_XXX(), and in that case,
collecting the number of block mappings for the range
[kernel_start, kernel_end) and adding conditional logic in
alloc_init_XXX() seems a bit odd.
That said, for potential future use cases involving splitting specific ranges,
I don’t think having this kind of collection is necessarily a bad idea.

>
> > > >
> > > > Second, for a future feature,
> > > > I hope to add some code to split "specfic" area to be spilt e.x)
> > > > to set a specific pkey for specific area.
> > > Could you give more detail on this? My working assumption is that either the
> > > system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
> > > linear map. If it does, we already have logic to split parts of the linear map
> > > when needed.
> > This is not for a linear mapping case. but for a "kernel text area".
> > As a draft, I want to mark some of kernel code can executable
> > both kernel and eBPF program.
> > (I'm trying to make eBPF program non-executable kernel code directly
> > with POE feature).
> > For this "executable area" both of kernel and eBPF program
> > -- typical example is exception entry, It need to split that specific
> > range and mark them with special POE index.
>
> IIUC, you want to change POE attributes for some kernel area (mainly in
> vmalloc address space). It sounds like you can do something like
> set_memory_rox(), but just split vmalloc address mapping instead of linear
> mapping. Or you need preallocate page table pages in this case? Anyway we
> can have more simple way to count block mappings for splitting linear
> mapping, it seems not necessary to re-walk page table again IMHO.

As I said, it isn't not only vmalloc address mapping but also
"kimage" mapping too.
In this case, it need to be split to set the specific code area
with specific POE index.

The preallocate page is for spliting via "stop_machine()"
since page table allocation with GFP_ATOMIC couldn't be in case of
PREEMPT_RT in stop_machine().

Also, the spliting text-code area to set specific POE index would be
done via stop_machine() so, the collection is required.

>
> >
> > > > In this case, it's useful to rewalk the page-table with the specific
> > > > range to get the number of block mapping.
> > > >
> > > > > > +	split_pgtables_idx = 0;
> > > > > > +	split_pgtables_count = 0;
> > > > > > +
> > > > > > +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
> > > > > > +						    &collect_to_split_ops,
> > > > > > +						    NULL, NULL);
> > > > > > +	if (!ret)
> > > > > > +		ret = walk_kernel_page_table_range_lockless(kend, lend,
> > > > > > +							    &collect_to_split_ops,
> > > > > > +							    NULL, NULL);
> > > > > > +	if (ret || !split_pgtables_count)
> > > > > > +		goto error;
> > > > > > +
> > > > > > +	ret = -ENOMEM;
> > > > > > +
> > > > > > +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
> > > > > > +				  GFP_KERNEL | __GFP_ZERO);
> > > > > > +	if (!split_pgtables)
> > > > > > +		goto error;
> > > > > > +
> > > > > > +	for (i = 0; i < split_pgtables_count; i++) {
> > > > > > +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
> > > > > > +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
> > > > > > +		if (!split_pgtables[i])
> > > > > > +			goto error;
> > > > > This looks potentially expensive on the boot path and only gets worse as
> > > > > the amount of memory grows. Maybe we should predicate this preallocation
> > > > > on preempt-rt?
> > > > Agree. then I'll apply pre-allocation with PREEMPT_RT only.
> > > I guess I'm missing something obvious but I don't understand the problem here...
> > > We are only deferring the allocation of all these pgtables, so the cost is
> > > neutral surely? Had we correctly guessed that the system doesn't support BBML2
> > > earlier, we would have had to allocate all these pgtables earlier.
> > >
> > > Another way to look at it is that we are still allocating the same number of
> > > pgtables in the existing fallback path, it's just that we are doing it inside
> > > the stop_machine().
> > >
> > > My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
> > > with significantly less testing...
> > IIUC, Will's mention is additional memory allocation for
> > "split_pgtables" where saved "pre-allocate" page tables.
> > As the memory increase, definitely this size would increase the cost.
> >
> > And this cost need not to burden for !PREEMPT_RT since
> > it can use memory allocation in stop_machine() with GFP_ATOMIC.
> >
> > But I also agree in the aspect that if that cost not much of huge,
> > It's also convincing and additionally, as I mentioned in another thread,
> > It would be good not to give a hallucination GFP_ATOMIC is fine for
> > everywhere even in the PREEMPT_RT.
> >
> > --
> > Sincerely,
> > Yeoreum Yun
>

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yang Shi]

On 1/20/26 3:01 PM, Yeoreum Yun wrote:
> Hi Yang,
>>
>> On 1/20/26 1:29 AM, Yeoreum Yun wrote:
>>> Hi Ryan
>>>> On 19/01/2026 21:24, Yeoreum Yun wrote:
>>>>> Hi Will,
>>>>>
>>>>>> On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
>>>>>>> +static int __init linear_map_prealloc_split_pgtables(void)
>>>>>>> +{
>>>>>>> +	int ret, i;
>>>>>>> +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
>>>>>>> +	unsigned long lend = PAGE_END;
>>>>>>> +	unsigned long kstart = (unsigned long)lm_alias(_stext);
>>>>>>> +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
>>>>>>> +
>>>>>>> +	const struct mm_walk_ops collect_to_split_ops = {
>>>>>>> +		.pud_entry	= collect_to_split_pud_entry,
>>>>>>> +		.pmd_entry	= collect_to_split_pmd_entry
>>>>>>> +	};
>>>>>> Why do we need to rewalk the page-table here instead of collating the
>>>>>> number of block mappings we put down when creating the linear map in
>>>>>> the first place?
>>>> That's a good point; perhaps we can reuse the counters that this series introduces?
>>>>
>>>> https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
>> Yeah, good point. It seems feasible to me. The patch can count how many
>> PUD/CONT_PMD/PMD mappings, we can calculate how many page table pages need
>> to be allocated based on those counters.
>>
>>>>> First, linear alias of the [_text, __init_begin) is not a target for
>>>>> the split and it also seems strange to me to add code inside alloc_init_XXX()
>>>>> that both checks an address range and counts to get the number of block mappings.
>> IIUC, it should be not that hard to exclude kernel mappings. We know
>> kernel_start and kernel_end, so you should be able to maintain a set of
>> counters for kernel, then minus them when you do the calculation for how
>> many page table pages need to be allocated.
> As you said, this is not difficult. However, what I meant was that
> this collection would be done in alloc_init_XXX(), and in that case,
> collecting the number of block mappings for the range
> [kernel_start, kernel_end) and adding conditional logic in
> alloc_init_XXX() seems a bit odd.
> That said, for potential future use cases involving splitting specific ranges,
> I don’t think having this kind of collection is necessarily a bad idea.

I'm not sure whether we are on the same page or not. IIUC the point is 
collecting the counts of PUD/CONT_PMD/PMD by re-walking page table is 
sub optimal and unnecessary for this usecase (repainting linear 
mapping). We can simply know the counts at linear mapping creation time.

I don't mean it is a bad idea for your future projects if it is necessary.

Thanks,
Yang

>
>>>>> Second, for a future feature,
>>>>> I hope to add some code to split "specfic" area to be spilt e.x)
>>>>> to set a specific pkey for specific area.
>>>> Could you give more detail on this? My working assumption is that either the
>>>> system supports BBML2 or it doesn't. If it doesn't, we need to split the whole
>>>> linear map. If it does, we already have logic to split parts of the linear map
>>>> when needed.
>>> This is not for a linear mapping case. but for a "kernel text area".
>>> As a draft, I want to mark some of kernel code can executable
>>> both kernel and eBPF program.
>>> (I'm trying to make eBPF program non-executable kernel code directly
>>> with POE feature).
>>> For this "executable area" both of kernel and eBPF program
>>> -- typical example is exception entry, It need to split that specific
>>> range and mark them with special POE index.
>> IIUC, you want to change POE attributes for some kernel area (mainly in
>> vmalloc address space). It sounds like you can do something like
>> set_memory_rox(), but just split vmalloc address mapping instead of linear
>> mapping. Or you need preallocate page table pages in this case? Anyway we
>> can have more simple way to count block mappings for splitting linear
>> mapping, it seems not necessary to re-walk page table again IMHO.
> As I said, it isn't not only vmalloc address mapping but also
> "kimage" mapping too.
> In this case, it need to be split to set the specific code area
> with specific POE index.
>
> The preallocate page is for spliting via "stop_machine()"
> since page table allocation with GFP_ATOMIC couldn't be in case of
> PREEMPT_RT in stop_machine().
>
> Also, the spliting text-code area to set specific POE index would be
> done via stop_machine() so, the collection is required.
>
>>>>> In this case, it's useful to rewalk the page-table with the specific
>>>>> range to get the number of block mapping.
>>>>>
>>>>>>> +	split_pgtables_idx = 0;
>>>>>>> +	split_pgtables_count = 0;
>>>>>>> +
>>>>>>> +	ret = walk_kernel_page_table_range_lockless(lstart, kstart,
>>>>>>> +						    &collect_to_split_ops,
>>>>>>> +						    NULL, NULL);
>>>>>>> +	if (!ret)
>>>>>>> +		ret = walk_kernel_page_table_range_lockless(kend, lend,
>>>>>>> +							    &collect_to_split_ops,
>>>>>>> +							    NULL, NULL);
>>>>>>> +	if (ret || !split_pgtables_count)
>>>>>>> +		goto error;
>>>>>>> +
>>>>>>> +	ret = -ENOMEM;
>>>>>>> +
>>>>>>> +	split_pgtables = kvmalloc(split_pgtables_count * sizeof(struct ptdesc *),
>>>>>>> +				  GFP_KERNEL | __GFP_ZERO);
>>>>>>> +	if (!split_pgtables)
>>>>>>> +		goto error;
>>>>>>> +
>>>>>>> +	for (i = 0; i < split_pgtables_count; i++) {
>>>>>>> +		/* The page table will be filled during splitting, so zeroing it is unnecessary. */
>>>>>>> +		split_pgtables[i] = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_ZERO, 0);
>>>>>>> +		if (!split_pgtables[i])
>>>>>>> +			goto error;
>>>>>> This looks potentially expensive on the boot path and only gets worse as
>>>>>> the amount of memory grows. Maybe we should predicate this preallocation
>>>>>> on preempt-rt?
>>>>> Agree. then I'll apply pre-allocation with PREEMPT_RT only.
>>>> I guess I'm missing something obvious but I don't understand the problem here...
>>>> We are only deferring the allocation of all these pgtables, so the cost is
>>>> neutral surely? Had we correctly guessed that the system doesn't support BBML2
>>>> earlier, we would have had to allocate all these pgtables earlier.
>>>>
>>>> Another way to look at it is that we are still allocating the same number of
>>>> pgtables in the existing fallback path, it's just that we are doing it inside
>>>> the stop_machine().
>>>>
>>>> My vote would be _not_ to have a separate path for PREEMPT_RT, which will end up
>>>> with significantly less testing...
>>> IIUC, Will's mention is additional memory allocation for
>>> "split_pgtables" where saved "pre-allocate" page tables.
>>> As the memory increase, definitely this size would increase the cost.
>>>
>>> And this cost need not to burden for !PREEMPT_RT since
>>> it can use memory allocation in stop_machine() with GFP_ATOMIC.
>>>
>>> But I also agree in the aspect that if that cost not much of huge,
>>> It's also convincing and additionally, as I mentioned in another thread,
>>> It would be good not to give a hallucination GFP_ATOMIC is fine for
>>> everywhere even in the PREEMPT_RT.
>>>
>>> --
>>> Sincerely,
>>> Yeoreum Yun
> --
> Sincerely,
> Yeoreum Yun

Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun]

Hi Yang,
>
>
> On 1/20/26 3:01 PM, Yeoreum Yun wrote:
> > Hi Yang,
> > >
> > > On 1/20/26 1:29 AM, Yeoreum Yun wrote:
> > > > Hi Ryan
> > > > > On 19/01/2026 21:24, Yeoreum Yun wrote:
> > > > > > Hi Will,
> > > > > >
> > > > > > > On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> > > > > > > > +static int __init linear_map_prealloc_split_pgtables(void)
> > > > > > > > +{
> > > > > > > > +	int ret, i;
> > > > > > > > +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> > > > > > > > +	unsigned long lend = PAGE_END;
> > > > > > > > +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> > > > > > > > +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> > > > > > > > +
> > > > > > > > +	const struct mm_walk_ops collect_to_split_ops = {
> > > > > > > > +		.pud_entry	= collect_to_split_pud_entry,
> > > > > > > > +		.pmd_entry	= collect_to_split_pmd_entry
> > > > > > > > +	};
> > > > > > > Why do we need to rewalk the page-table here instead of collating the
> > > > > > > number of block mappings we put down when creating the linear map in
> > > > > > > the first place?
> > > > > That's a good point; perhaps we can reuse the counters that this series introduces?
> > > > >
> > > > > https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> > > Yeah, good point. It seems feasible to me. The patch can count how many
> > > PUD/CONT_PMD/PMD mappings, we can calculate how many page table pages need
> > > to be allocated based on those counters.
> > >
> > > > > > First, linear alias of the [_text, __init_begin) is not a target for
> > > > > > the split and it also seems strange to me to add code inside alloc_init_XXX()
> > > > > > that both checks an address range and counts to get the number of block mappings.
> > > IIUC, it should be not that hard to exclude kernel mappings. We know
> > > kernel_start and kernel_end, so you should be able to maintain a set of
> > > counters for kernel, then minus them when you do the calculation for how
> > > many page table pages need to be allocated.
> > As you said, this is not difficult. However, what I meant was that
> > this collection would be done in alloc_init_XXX(), and in that case,
> > collecting the number of block mappings for the range
> > [kernel_start, kernel_end) and adding conditional logic in
> > alloc_init_XXX() seems a bit odd.
> > That said, for potential future use cases involving splitting specific ranges,
> > I don’t think having this kind of collection is necessarily a bad idea.
>
> I'm not sure whether we are on the same page or not. IIUC the point is
> collecting the counts of PUD/CONT_PMD/PMD by re-walking page table is sub
> optimal and unnecessary for this usecase (repainting linear mapping). We can
> simply know the counts at linear mapping creation time.

What I meant was that the counts collected via dm_meminfo already
include kernel aliases, so adding separate code to
count kernel aliases again seems odd to me.
That said, I do not disagree with the efficiency of
using the already collected counts.

Thanks!

[...]

--
Sincerely,
Yeoreum Yun

[PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI

[Yeoreum Yun]

The current __kpti_install_ng_mappings() allocates a temporary PGD
while installing the NG mapping for KPTI under stop_machine(),
using GFP_ATOMIC.

This is fine in the non-PREEMPT_RT case. However, it becomes a problem
under PREEMPT_RT because generic memory allocation/free APIs
(e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
in a non-preemptible context, except for the *_nolock() variants.
These generic allocators may sleep due to their use of spin_lock().

In other words, calling __get_free_pages(), even with GFP_ATOMIC,
is not allowed in __kpti_install_ng_mappings(), which is executed by
the stopper thread where preemption is disabled under PREEMPT_RT.

To address this, preallocate the page needed for the temporary PGD
before invoking __kpti_install_ng_mappings() via stop_machine().

Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
---
 arch/arm64/mm/mmu.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 120874a2d35b..6ea5b80ab54f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
 	return kpti_ng_temp_alloc;
 }
 
-static int __init __kpti_install_ng_mappings(void *__unused)
+static int __init __kpti_install_ng_mappings(void *data)
 {
 	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
 	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
@@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
 
 	int cpu = smp_processor_id();
 	int levels = CONFIG_PGTABLE_LEVELS;
-	int order = order_base_2(levels);
 	u64 kpti_ng_temp_pgd_pa = 0;
 	pgd_t *kpti_ng_temp_pgd;
-	u64 alloc = 0;
+	u64 alloc = *(u64 *)data;
 
 	if (levels == 5 && !pgtable_l5_enabled())
 		levels = 4;
@@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
 
 	if (!cpu) {
 		int ret;
-
-		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
 		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
 		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
 
@@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
 	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
 	cpu_uninstall_idmap();
 
-	if (!cpu) {
-		free_pages(alloc, order);
+	if (!cpu)
 		arm64_use_ng_mappings = true;
-	}
 
 	return 0;
 }
 
 void __init kpti_install_ng_mappings(void)
 {
+	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
+	u64 alloc;
 	/* Check whether KPTI is going to be used */
 	if (!arm64_kernel_unmapped_at_el0())
 		return;
@@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
 	if (arm64_use_ng_mappings)
 		return;
 
+	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
+	if (!alloc)
+		panic("Failed to alloc page tables\n");
+
 	init_idmap_kpti_bbml2_flag();
-	stop_machine(__kpti_install_ng_mappings, NULL, cpu_online_mask);
+	stop_machine(__kpti_install_ng_mappings, &alloc, cpu_online_mask);
+
+	free_pages(alloc, order);
 }
 
 static pgprot_t __init kernel_exec_prot(void)
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI

[Will Deacon]

On Mon, Jan 05, 2026 at 08:23:28PM +0000, Yeoreum Yun wrote:
> The current __kpti_install_ng_mappings() allocates a temporary PGD
> while installing the NG mapping for KPTI under stop_machine(),
> using GFP_ATOMIC.
> 
> This is fine in the non-PREEMPT_RT case. However, it becomes a problem
> under PREEMPT_RT because generic memory allocation/free APIs
> (e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
> in a non-preemptible context, except for the *_nolock() variants.
> These generic allocators may sleep due to their use of spin_lock().
> 
> In other words, calling __get_free_pages(), even with GFP_ATOMIC,
> is not allowed in __kpti_install_ng_mappings(), which is executed by
> the stopper thread where preemption is disabled under PREEMPT_RT.
> 
> To address this, preallocate the page needed for the temporary PGD
> before invoking __kpti_install_ng_mappings() via stop_machine().
> 
> Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
>  arch/arm64/mm/mmu.c | 21 ++++++++++++---------
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 120874a2d35b..6ea5b80ab54f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
>  	return kpti_ng_temp_alloc;
>  }
>  
> -static int __init __kpti_install_ng_mappings(void *__unused)
> +static int __init __kpti_install_ng_mappings(void *data)
>  {
>  	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
>  	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
> @@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
>  
>  	int cpu = smp_processor_id();
>  	int levels = CONFIG_PGTABLE_LEVELS;
> -	int order = order_base_2(levels);
>  	u64 kpti_ng_temp_pgd_pa = 0;
>  	pgd_t *kpti_ng_temp_pgd;
> -	u64 alloc = 0;
> +	u64 alloc = *(u64 *)data;
>  
>  	if (levels == 5 && !pgtable_l5_enabled())
>  		levels = 4;
> @@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
>  
>  	if (!cpu) {
>  		int ret;
> -
> -		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
>  		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
>  		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
>  
> @@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
>  	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
>  	cpu_uninstall_idmap();
>  
> -	if (!cpu) {
> -		free_pages(alloc, order);
> +	if (!cpu)
>  		arm64_use_ng_mappings = true;
> -	}
>  
>  	return 0;
>  }
>  
>  void __init kpti_install_ng_mappings(void)
>  {
> +	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
> +	u64 alloc;
>  	/* Check whether KPTI is going to be used */
>  	if (!arm64_kernel_unmapped_at_el0())
>  		return;
> @@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
>  	if (arm64_use_ng_mappings)
>  		return;
>  
> +	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> +	if (!alloc)
> +		panic("Failed to alloc page tables\n");

Why are you adding this panic?

Will

Re: [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI

[Yeoreum Yun]

Hi Will,

> On Mon, Jan 05, 2026 at 08:23:28PM +0000, Yeoreum Yun wrote:
> > The current __kpti_install_ng_mappings() allocates a temporary PGD
> > while installing the NG mapping for KPTI under stop_machine(),
> > using GFP_ATOMIC.
> >
> > This is fine in the non-PREEMPT_RT case. However, it becomes a problem
> > under PREEMPT_RT because generic memory allocation/free APIs
> > (e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
> > in a non-preemptible context, except for the *_nolock() variants.
> > These generic allocators may sleep due to their use of spin_lock().
> >
> > In other words, calling __get_free_pages(), even with GFP_ATOMIC,
> > is not allowed in __kpti_install_ng_mappings(), which is executed by
> > the stopper thread where preemption is disabled under PREEMPT_RT.
> >
> > To address this, preallocate the page needed for the temporary PGD
> > before invoking __kpti_install_ng_mappings() via stop_machine().
> >
> > Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> > ---
> >  arch/arm64/mm/mmu.c | 21 ++++++++++++---------
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 120874a2d35b..6ea5b80ab54f 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
> >  	return kpti_ng_temp_alloc;
> >  }
> >
> > -static int __init __kpti_install_ng_mappings(void *__unused)
> > +static int __init __kpti_install_ng_mappings(void *data)
> >  {
> >  	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
> >  	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
> > @@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >
> >  	int cpu = smp_processor_id();
> >  	int levels = CONFIG_PGTABLE_LEVELS;
> > -	int order = order_base_2(levels);
> >  	u64 kpti_ng_temp_pgd_pa = 0;
> >  	pgd_t *kpti_ng_temp_pgd;
> > -	u64 alloc = 0;
> > +	u64 alloc = *(u64 *)data;
> >
> >  	if (levels == 5 && !pgtable_l5_enabled())
> >  		levels = 4;
> > @@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >
> >  	if (!cpu) {
> >  		int ret;
> > -
> > -		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
> >  		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
> >  		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
> >
> > @@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >  	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
> >  	cpu_uninstall_idmap();
> >
> > -	if (!cpu) {
> > -		free_pages(alloc, order);
> > +	if (!cpu)
> >  		arm64_use_ng_mappings = true;
> > -	}
> >
> >  	return 0;
> >  }
> >
> >  void __init kpti_install_ng_mappings(void)
> >  {
> > +	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
> > +	u64 alloc;
> >  	/* Check whether KPTI is going to be used */
> >  	if (!arm64_kernel_unmapped_at_el0())
> >  		return;
> > @@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
> >  	if (arm64_use_ng_mappings)
> >  		return;
> >
> > +	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> > +	if (!alloc)
> > +		panic("Failed to alloc page tables\n");
>
> Why are you adding this panic?

Because original code call the panic() when it fails to create
mapping of kpti_ng_temp_pgd and I think allocation is also part
of creating kpti_ng_temp_pgd too.
So, I added this panic() when allocation is failed for kpti_ng_temp_pgd.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI

[Will Deacon]

On Mon, Jan 19, 2026 at 09:30:30PM +0000, Yeoreum Yun wrote:
> Hi Will,
> 
> > On Mon, Jan 05, 2026 at 08:23:28PM +0000, Yeoreum Yun wrote:
> > > The current __kpti_install_ng_mappings() allocates a temporary PGD
> > > while installing the NG mapping for KPTI under stop_machine(),
> > > using GFP_ATOMIC.
> > >
> > > This is fine in the non-PREEMPT_RT case. However, it becomes a problem
> > > under PREEMPT_RT because generic memory allocation/free APIs
> > > (e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
> > > in a non-preemptible context, except for the *_nolock() variants.
> > > These generic allocators may sleep due to their use of spin_lock().
> > >
> > > In other words, calling __get_free_pages(), even with GFP_ATOMIC,
> > > is not allowed in __kpti_install_ng_mappings(), which is executed by
> > > the stopper thread where preemption is disabled under PREEMPT_RT.
> > >
> > > To address this, preallocate the page needed for the temporary PGD
> > > before invoking __kpti_install_ng_mappings() via stop_machine().
> > >
> > > Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> > > ---
> > >  arch/arm64/mm/mmu.c | 21 ++++++++++++---------
> > >  1 file changed, 12 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 120874a2d35b..6ea5b80ab54f 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
> > >  	return kpti_ng_temp_alloc;
> > >  }
> > >
> > > -static int __init __kpti_install_ng_mappings(void *__unused)
> > > +static int __init __kpti_install_ng_mappings(void *data)
> > >  {
> > >  	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
> > >  	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
> > > @@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > >
> > >  	int cpu = smp_processor_id();
> > >  	int levels = CONFIG_PGTABLE_LEVELS;
> > > -	int order = order_base_2(levels);
> > >  	u64 kpti_ng_temp_pgd_pa = 0;
> > >  	pgd_t *kpti_ng_temp_pgd;
> > > -	u64 alloc = 0;
> > > +	u64 alloc = *(u64 *)data;
> > >
> > >  	if (levels == 5 && !pgtable_l5_enabled())
> > >  		levels = 4;
> > > @@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > >
> > >  	if (!cpu) {
> > >  		int ret;
> > > -
> > > -		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
> > >  		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
> > >  		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
> > >
> > > @@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > >  	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
> > >  	cpu_uninstall_idmap();
> > >
> > > -	if (!cpu) {
> > > -		free_pages(alloc, order);
> > > +	if (!cpu)
> > >  		arm64_use_ng_mappings = true;
> > > -	}
> > >
> > >  	return 0;
> > >  }
> > >
> > >  void __init kpti_install_ng_mappings(void)
> > >  {
> > > +	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
> > > +	u64 alloc;
> > >  	/* Check whether KPTI is going to be used */
> > >  	if (!arm64_kernel_unmapped_at_el0())
> > >  		return;
> > > @@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
> > >  	if (arm64_use_ng_mappings)
> > >  		return;
> > >
> > > +	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> > > +	if (!alloc)
> > > +		panic("Failed to alloc page tables\n");
> >
> > Why are you adding this panic?
> 
> Because original code call the panic() when it fails to create
> mapping of kpti_ng_temp_pgd and I think allocation is also part
> of creating kpti_ng_temp_pgd too.
> So, I added this panic() when allocation is failed for kpti_ng_temp_pgd.

No. The current code seems to assume the allocation will succeed and
panic()s if the call to __create_pgd_mapping_locked() returns an error.

Just make this:

	if (WARN_ON(!alloc))
		return;

Will

Re: [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI

[Yeoreum Yun]

> On Mon, Jan 19, 2026 at 09:30:30PM +0000, Yeoreum Yun wrote:
> > Hi Will,
> >
> > > On Mon, Jan 05, 2026 at 08:23:28PM +0000, Yeoreum Yun wrote:
> > > > The current __kpti_install_ng_mappings() allocates a temporary PGD
> > > > while installing the NG mapping for KPTI under stop_machine(),
> > > > using GFP_ATOMIC.
> > > >
> > > > This is fine in the non-PREEMPT_RT case. However, it becomes a problem
> > > > under PREEMPT_RT because generic memory allocation/free APIs
> > > > (e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
> > > > in a non-preemptible context, except for the *_nolock() variants.
> > > > These generic allocators may sleep due to their use of spin_lock().
> > > >
> > > > In other words, calling __get_free_pages(), even with GFP_ATOMIC,
> > > > is not allowed in __kpti_install_ng_mappings(), which is executed by
> > > > the stopper thread where preemption is disabled under PREEMPT_RT.
> > > >
> > > > To address this, preallocate the page needed for the temporary PGD
> > > > before invoking __kpti_install_ng_mappings() via stop_machine().
> > > >
> > > > Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> > > > ---
> > > >  arch/arm64/mm/mmu.c | 21 ++++++++++++---------
> > > >  1 file changed, 12 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > > index 120874a2d35b..6ea5b80ab54f 100644
> > > > --- a/arch/arm64/mm/mmu.c
> > > > +++ b/arch/arm64/mm/mmu.c
> > > > @@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
> > > >  	return kpti_ng_temp_alloc;
> > > >  }
> > > >
> > > > -static int __init __kpti_install_ng_mappings(void *__unused)
> > > > +static int __init __kpti_install_ng_mappings(void *data)
> > > >  {
> > > >  	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
> > > >  	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
> > > > @@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > > >
> > > >  	int cpu = smp_processor_id();
> > > >  	int levels = CONFIG_PGTABLE_LEVELS;
> > > > -	int order = order_base_2(levels);
> > > >  	u64 kpti_ng_temp_pgd_pa = 0;
> > > >  	pgd_t *kpti_ng_temp_pgd;
> > > > -	u64 alloc = 0;
> > > > +	u64 alloc = *(u64 *)data;
> > > >
> > > >  	if (levels == 5 && !pgtable_l5_enabled())
> > > >  		levels = 4;
> > > > @@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > > >
> > > >  	if (!cpu) {
> > > >  		int ret;
> > > > -
> > > > -		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
> > > >  		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
> > > >  		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
> > > >
> > > > @@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> > > >  	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
> > > >  	cpu_uninstall_idmap();
> > > >
> > > > -	if (!cpu) {
> > > > -		free_pages(alloc, order);
> > > > +	if (!cpu)
> > > >  		arm64_use_ng_mappings = true;
> > > > -	}
> > > >
> > > >  	return 0;
> > > >  }
> > > >
> > > >  void __init kpti_install_ng_mappings(void)
> > > >  {
> > > > +	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
> > > > +	u64 alloc;
> > > >  	/* Check whether KPTI is going to be used */
> > > >  	if (!arm64_kernel_unmapped_at_el0())
> > > >  		return;
> > > > @@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
> > > >  	if (arm64_use_ng_mappings)
> > > >  		return;
> > > >
> > > > +	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> > > > +	if (!alloc)
> > > > +		panic("Failed to alloc page tables\n");
> > >
> > > Why are you adding this panic?
> >
> > Because original code call the panic() when it fails to create
> > mapping of kpti_ng_temp_pgd and I think allocation is also part
> > of creating kpti_ng_temp_pgd too.
> > So, I added this panic() when allocation is failed for kpti_ng_temp_pgd.
>
> No. The current code seems to assume the allocation will succeed and
> panic()s if the call to __create_pgd_mapping_locked() returns an error.
>
> Just make this:
>
> 	if (WARN_ON(!alloc))
> 		return;
>

Okay I'll change with this.

Thanks.

--
Sincerely,
Yeoreum Yun