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

[Vivian Wang]

On 7/10/26 09:58, Paul Walmsley wrote:

> Hi Vivian,
>
> On Tue, 7 Jul 2026, Vivian Wang wrote:
>
>> [...]
>>
>> 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.

I do think end <= VMEMMAP_END is correct.
Documentation/core-api/cachetlb.rst says:

6) ``void flush_cache_vmap(unsigned long start, unsigned long end)``
   ``void flush_cache_vunmap(unsigned long start, unsigned long end)``

    Here in these two interfaces we are flushing a specific range
    of (kernel) virtual addresses from the cache.  After running,
    there will be no entries in the cache for the kernel address
    space for virtual addresses in the range 'start' to 'end-1'.
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So this is one of those half-open ranges. When end == VMEMMAP_END, it
means that the end of the range is exactly at the end of the vmemmap.

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

Yes I will. There's an extraneous hunk for arch/riscv/mm/init.c that I
accidentally added to this patch, which was the thing that prompted the
"oops I'll send a v6 to fix" earlier. And there's a build failure for
MMU=n, which I will also fix for v6. (Why is this code even compiled for
MMU=n...)

(Muchun: Also thanks for the hint on the latter point reported by Sashiko.)

I haven't been able to get to it this week, unfortunately. I'll
definitely get to it next week if possible.

Vivian "dramforever" Wang