[PATCH v5] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap
Vivian Wang
wangruikang at iscas.ac.cn
Mon Jul 6 22:03:43 PDT 2026
Please disregard. I made a mistake while submitting this patch.
I'll send a fixed v6 later. Sorry.
On 7/7/26 12:10, 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 at linux.dev>
> Signed-off-by: Vivian Wang <wangruikang at iscas.ac.cn>
> ---
[...]
More information about the linux-riscv
mailing list