Index-based cache operations may be arbitrarily reordered by out of order CPUs. Thus code which writes back the dcache & then invalidates the icache using indexed cache ops must include a barrier between operating on the 2 caches in order to prevent the scenario in which: - icache invalidation occurs. - icache fetch occurs, due to speculation. - dcache writeback occurs. If the above were allowed to happen then the icache would contain stale data. Forcing the dcache writeback to complete before the icache invalidation avoids this. Similarly, the MIPS CM version 2 and above serialises D->I hit-based cache operations to the same address, but older CMs and systems without a MIPS CM do not and require the same barrier to ensure ordering. To ensure these conditions, always enforce a barrier between D and I cache operations. Suggested-by: Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxx> Suggested-by: Paul Burton <paul.burton@xxxxxxxx> Signed-off-by: Matt Redfearn <matt.redfearn@xxxxxxxx> Cc: James Hogan <james.hogan@xxxxxxxx> Cc: stable <stable@xxxxxxxxxxxxxxx> # v4.9+ --- arch/mips/mm/c-r4k.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index ce7a54223504..b7186d47184b 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -741,6 +741,9 @@ static inline void __local_r4k_flush_icache_range(unsigned long start, else blast_dcache_range(start, end); } + + /* Ensure dcache operation has completed */ + mb(); } if (type == R4K_INDEX || -- 2.7.4