Re: [PATCH] MIPS: c-r4k: Flush the cache error vector before writing it uncached

[Maciej W. Rozycki]

On Wed, 21 Oct 2026, Imre Kaloz wrote:

> On R10000-class CPUs, a store prefetch while copying the preceding
> vector can leave a dirty line whose write-back overwrites the uncached
> cache error handler. Flush it first in r4k_cache_error_setup() with
> r4k_dma_cache_wback_inv(), as dma_cache_wback_inv() is a no-op on
> coherent systems.
> 
> Fixes: e01402b115cc ("More AP / SP bits for the 34K, the Malta bits and things.  Still wants a little polishing.")

 This is surely not the right commit to pick, as that was merely code 
refactoring and the issue existed before it.

> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index d8aadd3dc057..ae31966ac65b 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -1684,6 +1684,14 @@ static void r4k_cache_error_setup(void)
>  	extern char __weak except_vec2_generic;
>  	extern char __weak except_vec2_sb1;
>  
> +	/*
> +	 * The handler is written uncached. Copying the preceding vector
> +	 * may have left a dirty cached line of it behind, through a store
> +	 * prefetch or a speculative store; write it back and invalidate it
> +	 * first, or its later write-back overwrites the handler.
> +	 */
> +	r4k_dma_cache_wback_inv(ebase + 0x100, 0x80);
> +

 Conceptually this seems right to me, however I think the call ought to be 
moved into set_uncached_handler() itself.  Also since you're repurposing a 
DMA handler, which the removal of CONFIG_DMA_NONCOHERENT wrapping makes so 
obvious, this asks for the function to be renamed.

 Thank you for your submission overall.

  Maciej