[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 at 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 at linux.dev>
> Signed-off-by: Vivian Wang <wangruikang at iscas.ac.cn>

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

Thanks.