[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 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.

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 at linux.dev>
>> Signed-off-by: Vivian Wang <wangruikang at iscas.ac.cn>
> Reviewed-by: Muchun Song <muchun.song at linux.dev>

Thanks for your review.

Vivian "dramforever" Wang