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

[Muchun Song <muchun.song@linux.dev>]

> On Jul 7, 2026, at 13:03, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> 
> Please disregard. I made a mistake while submitting this patch.
> 
> I'll send a fixed v6 later. Sorry.

Please fix issues reported by Sashiko excluding pre-existing ones.

Thanks.

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