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

[Paul Walmsley <pjw@kernel.org>]

Hi Vivian,

On Tue, 7 Jul 2026, 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>
> ---
> 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)
> ---
>  arch/riscv/include/asm/cacheflush.h | 3 ++-
>  arch/riscv/mm/init.c                | 1 +
>  mm/sparse-vmemmap.c                 | 2 ++
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
> index 8cfe59483a8f..e935db27f09f 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))

Is there an off-by-one error here?  VMEMMAP_END is currently set to
VMALLOC_START on RISC-V.

Am assuming you'll update this patch one more time?  At that point I'll 
plan to add it into v7.2-rc, assuming Andrew doesn't object.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv