Commit 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
switches initial TLB flushing to a mode needed for microAptiv/M5150
cores.  This breaks (at least) R4x00 cores if the tlb probe hits
multiple matching TLB entries (SGI IP22 prom for examples sets up all
TLBs to the same virtual address). Use the new TLB flushing only on
M5150 and local_tlb_flush_all() for everything else.

Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 arch/mips/mm/tlb-r4k.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index 347126dc010d..c39a16d377a1 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -601,7 +601,10 @@ static void r4k_tlb_configure(void)
 	temp_tlb_entry = current_cpu_data.tlbsize - 1;
 
 	/* From this point on the ARC firmware is dead.	 */
-	r4k_tlb_uniquify();
+	if (current_cpu_type() == CPU_M5150)
+		r4k_tlb_uniquify();
+	else
+		local_flush_tlb_all();
 
 	/* Did I tell you that ARC SUCKS?  */
 }
-- 
2.43.0

On Mon, 10 Nov 2025, Thomas Bogendoerfer wrote:

> Commit 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> switches initial TLB flushing to a mode needed for microAptiv/M5150
> cores.  This breaks (at least) R4x00 cores if the tlb probe hits
> multiple matching TLB entries (SGI IP22 prom for examples sets up all
> TLBs to the same virtual address). Use the new TLB flushing only on
> M5150 and local_tlb_flush_all() for everything else.

 This surely isn't enough.  Even the plain old 4Kc core will trigger an 
MCheck under the same condition.  The fix surely has to be more general.  

 Perhaps we should take the simplest approach: read all the TLB entries 
with TLBR, sort them by their VPN value and deduplicate to be able to 
search for a match quickly, assign and write temporary VPN values outside 
our unique range avoiding a clash with any of the values obtained, and 
then finally call local_tlb_flush_all().

 This will require some memory and the computational complexity may exceed 
O(n), but our TLBs are small with their size architecturally limited to 64 
entries, so it's not a big deal in reality and this code will only execute 
once at boot.

  Maciej

On Mon, 10 Nov 2025, Maciej W. Rozycki wrote:

>  Perhaps we should take the simplest approach: read all the TLB entries 
> with TLBR, sort them by their VPN value and deduplicate to be able to 
> search for a match quickly, assign and write temporary VPN values outside 
> our unique range avoiding a clash with any of the values obtained, and 
> then finally call local_tlb_flush_all().

 And now implemented; no deduplication needed after all.  Cf. 
<https://lore.kernel.org/linux-mips/alpine.DEB.2.21.2511110547430.25436@angie.orcam.me.uk/>.

  Maciej