Re: [PATCH 2/2] sparc64: flush vmalloc ranges from the D-cache on map and unmap

[Stian Halseth]

Hi Imre,

On Sun, 2026-09-27 at 12:55 +0200, Imre Kaloz wrote:
> +void flush_cache_vmap(unsigned long start, unsigned long end)
> +{
> +#ifdef DCACHE_ALIASING_POSSIBLE
> +	if (tlb_type == hypervisor)
> +		return;

I found that this also runs early in boot, on the vmemmap.
__populate_section_memmap() calls it from sparse_init(). That is before
init_IRQ() has set up the cross-call mondo blocks, so xcall_deliver()
writes its three mondo words through __va(0), to physical address 0.

On SMP, cpu_data() is not filled in yet either, so dcache_size is 0 and
the flush itself does nothing useful.

Physical address 0 is ordinary RAM on the Sun Fire V240. In a test it
held zeros before the first of these cross-calls, and the three mondo
words after. The kernel uses that page later in boot. This happens
once per memory section, four times here.

Since the vmemmap has no aliases to flush, I suggest we skip anything
outside vmalloc and module space, like this:

        if (tlb_type == hypervisor ||
            !is_vmalloc_or_module_addr((void *)start))
                return;

With that, the V240 makes no cross-calls before init_IRQ().

Tested on a Sun Fire V240 with a module that reads a page through a
vmalloc address, rewrites it through the linear map on the same CPU and
maps it again at the same address: stale data in nearly every iteration
before, none after. Our V240s never showed #29 (no bpf() syscall
there), so that is a synthetic test. No change on a T4-1 with the
series as posted.

With the vmemmap check:
Tested-by: Stian Halseth <stian@xxxxxx> # Sun Fire V240, SPARC T4-1

Attachment: signature.asc
Description: This is a digitally signed message part