[PATCH v6 0/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[PATCH v6 0/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[Vivian Wang]

Patch 1 is a bit of clean up that fixes the compilation error with patch
2, since VMEMMAP_{START,END} is not defined when MMU=n.

The mark_new_valid_map() thing doesn't do anything useful on MMU=n
anyway, and the new_valid_maps_cpus_check code is only used on 64BIT, so
I just made it all of it conditional on 64BIT && MMU. I hope this is
acceptable.

---
Changes in v6:
- New patch 1, make all mark_new_valid_map() stuff depend on 64BIT &&
  MMU. Both cleanup and fixes build error with MMU=n. (Muchun)
- Remove extraneous change to arch/riscv/mm/init.c
- Link to v5: https://patch.msgid.link/20260707-mark-after-vmemmap-populate-v5-1-77d1ded3cae3@iscas.ac.cn

Changes in v5:
- Remove hook, use existing flush_cache_vmap() (Muchun)
- Link to v4: https://patch.msgid.link/20260630-mark-after-vmemmap-populate-v4-1-febbc15da028@iscas.ac.cn

Changes in v4:
- Rebase on v7.2-rc1, drop dependencies
- (No code changes otherwise)
- (A concurrency fix for mark_new_valid_map was sent independently)
  https://lore.kernel.org/linux-riscv/20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn/
- Link to v3: https://patch.msgid.link/20260605-mark-after-vmemmap-populate-v3-1-a06001ac9264@iscas.ac.cn

(See v3 link for older changes)

---
Vivian Wang (2):
      riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMU
      mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

 arch/riscv/include/asm/cacheflush.h | 5 +++--
 arch/riscv/kernel/entry.S           | 2 +-
 arch/riscv/mm/init.c                | 2 ++
 mm/sparse-vmemmap.c                 | 2 ++
 4 files changed, 8 insertions(+), 3 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260525-mark-after-vmemmap-populate-68bd790839c9

Best regards,
--  
Vivian "dramforever" Wang

[PATCH v6 1/2] riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMU

[Vivian Wang]

None of the code relating to mark_new_valid_map() does anything useful
without CONFIG_64BIT=y && CONFIG_MMU=y, because the
new_valid_map_cpus_check code is only used if CONFIG_64BIT, and the
exception codes checked there can only happen with CONFIG_MMU=y.

Therefore, make these conditional on CONFIG_64BIT=y && CONFIG_MMU=y to
simplify programming, since we do not have to handle CONFIG_MMU=n when
changing this code in the future. This also removes some unused code on
the entry path for CONFIG_MMU=n.

Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
---
 arch/riscv/include/asm/cacheflush.h | 2 +-
 arch/riscv/kernel/entry.S           | 2 +-
 arch/riscv/mm/init.c                | 2 ++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
index 8cfe59483a8f..58e787fad029 100644
--- a/arch/riscv/include/asm/cacheflush.h
+++ b/arch/riscv/include/asm/cacheflush.h
@@ -40,7 +40,7 @@ do {							\
 		flush_icache_mm(vma->vm_mm, 0);		\
 } while (0)
 
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
 /* This is accessed in assembly code. cpumask_var_t would be too complex. */
 extern DECLARE_BITMAP(new_valid_map_cpus, NR_CPUS);
 extern char _end[];
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index c6988983cdf7..3ae498779adf 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -137,7 +137,7 @@ SYM_CODE_START(handle_exception)
 .Lrestore_kernel_tpsp:
 	csrr tp, CSR_SCRATCH
 
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
 	/*
 	 * The RISC-V kernel does not flush TLBs on all CPUS after each new
 	 * vmalloc mapping or kfence_unprotect(), which may result in
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 5b1b3c88b4d1..3e450890be07 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -37,7 +37,9 @@
 
 #include "../kernel/head.h"
 
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
 DECLARE_BITMAP(new_valid_map_cpus, NR_CPUS);
+#endif
 
 struct kernel_mapping kernel_map __ro_after_init;
 EXPORT_SYMBOL(kernel_map);

-- 
2.54.0

[PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[Vivian Wang]

section_activate() does not flush TLB after populating new vmemmap
pages. On most architectures, this is okay. However it is a problem on
RISC-V since there the TLB caching non-present entries is permitted,
which causes spurious faults on some hardwares.

This seems to be most easily reproduced with DEBUG_VM=y and
PAGE_POISONING=y, which causes these newly mapped struct pages to be
poisoned i.e. written to immediately after mapping.

Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range,
and call it after hotplugging vmemmap, which gets the possible spurious
fault handled in the exception handler.

At least for now, the only other architecture with both
SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar
problem with newly valid PTEs. But there flush_cache_vmap() is just a
ptesync. So it should be safe to do this for generic code while having
minimal performance impact.

Suggested-by: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
---
 arch/riscv/include/asm/cacheflush.h | 3 ++-
 mm/sparse-vmemmap.c                 | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
index 58e787fad029..c2b0a2928f06 100644
--- a/arch/riscv/include/asm/cacheflush.h
+++ b/arch/riscv/include/asm/cacheflush.h
@@ -56,7 +56,8 @@ static inline void mark_new_valid_map(void)
 #define flush_cache_vmap flush_cache_vmap
 static inline void flush_cache_vmap(unsigned long start, unsigned long end)
 {
-	if (is_vmalloc_or_module_addr((void *)start))
+	if (is_vmalloc_or_module_addr((void *)start) ||
+	    (start >= VMEMMAP_START && end <= VMEMMAP_END))
 		mark_new_valid_map();
 }
 #define flush_cache_vmap_early(start, end)	local_flush_tlb_kernel_range(start, end)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 99e2be39671b..ebd3ac997f64 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -564,6 +564,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
 	if (r < 0)
 		return NULL;
 
+	flush_cache_vmap(start, end);
+
 	return pfn_to_page(pfn);
 }
 

-- 
2.54.0

Re: [PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[Muchun Song]

> On Jul 13, 2026, at 14:15, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> 
> section_activate() does not flush TLB after populating new vmemmap
> pages. On most architectures, this is okay. However it is a problem on
> RISC-V since there the TLB caching non-present entries is permitted,
> which causes spurious faults on some hardwares.
> 
> This seems to be most easily reproduced with DEBUG_VM=y and
> PAGE_POISONING=y, which causes these newly mapped struct pages to be
> poisoned i.e. written to immediately after mapping.
> 
> Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range,
> and call it after hotplugging vmemmap, which gets the possible spurious
> fault handled in the exception handler.
> 
> At least for now, the only other architecture with both
> SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar
> problem with newly valid PTEs. But there flush_cache_vmap() is just a

PowerPC is actually unaffected here since it achieves the desired effect
via vmemmap_set_pmd. However, your patch will pave the way for a great
cleanup to remove PowerPC's architectural vmemmap_set_pmd, given that it
already relies on flush_cache_vmap() for the required barrier operations.

> ptesync. So it should be safe to do this for generic code while having
> minimal performance impact.

After the cleanup for the PowerPC, it will emit only once ptesync operation,
so it will be a minor performance improvement.

> 
> Suggested-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>

Reviewed-by: Muchun Song <muchun.song@linux.dev>

Thanks.

Re: [PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[Vivian Wang]

On 7/13/26 14:56, Muchun Song wrote:
>
>> On Jul 13, 2026, at 14:15, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>
>> section_activate() does not flush TLB after populating new vmemmap
>> pages. On most architectures, this is okay. However it is a problem on
>> RISC-V since there the TLB caching non-present entries is permitted,
>> which causes spurious faults on some hardwares.
>>
>> This seems to be most easily reproduced with DEBUG_VM=y and
>> PAGE_POISONING=y, which causes these newly mapped struct pages to be
>> poisoned i.e. written to immediately after mapping.
>>
>> Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range,
>> and call it after hotplugging vmemmap, which gets the possible spurious
>> fault handled in the exception handler.
>>
>> At least for now, the only other architecture with both
>> SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar
>> problem with newly valid PTEs. But there flush_cache_vmap() is just a
> PowerPC is actually unaffected here since it achieves the desired effect
> via vmemmap_set_pmd. However, your patch will pave the way for a great
> cleanup to remove PowerPC's architectural vmemmap_set_pmd, given that it
> already relies on flush_cache_vmap() for the required barrier operations.

I agree. I was just talking about PowerPC in general, which requires a
ptesync after "newly valid PTEs". In this sense, PowerPC in general is
affected.

>> ptesync. So it should be safe to do this for generic code while having
>> minimal performance impact.
> After the cleanup for the PowerPC, it will emit only once ptesync operation,
> so it will be a minor performance improvement.

I haven't mentioned the future cleanup because, well, future. Otherwise
I agree on this as well.

>> Suggested-by: Muchun Song <muchun.song@linux.dev>
>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> Reviewed-by: Muchun Song <muchun.song@linux.dev>

Thanks for your review.

Vivian "dramforever" Wang

Re: [PATCH v6 0/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[Paul Walmsley]

On Mon, 13 Jul 2026, Vivian Wang wrote:

> Patch 1 is a bit of clean up that fixes the compilation error with patch
> 2, since VMEMMAP_{START,END} is not defined when MMU=n.
> 
> The mark_new_valid_map() thing doesn't do anything useful on MMU=n
> anyway, and the new_valid_maps_cpus_check code is only used on 64BIT, so
> I just made it all of it conditional on 64BIT && MMU. I hope this is
> acceptable.

Thanks, queued for v7.2-rc.


- Paul

Re: [PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

[David Hildenbrand (Arm)]

On 7/13/26 08:15, Vivian Wang wrote:
> section_activate() does not flush TLB after populating new vmemmap
> pages. On most architectures, this is okay. However it is a problem on
> RISC-V since there the TLB caching non-present entries is permitted,
> which causes spurious faults on some hardwares.
> 
> This seems to be most easily reproduced with DEBUG_VM=y and
> PAGE_POISONING=y, which causes these newly mapped struct pages to be
> poisoned i.e. written to immediately after mapping.
> 
> Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range,
> and call it after hotplugging vmemmap, which gets the possible spurious
> fault handled in the exception handler.
> 
> At least for now, the only other architecture with both
> SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar
> problem with newly valid PTEs. But there flush_cache_vmap() is just a
> ptesync. So it should be safe to do this for generic code while having
> minimal performance impact.
> 
> Suggested-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> ---

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David