summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorPaul Burton <paulburton@kernel.org>2019-10-18 15:38:48 -0700
committerPaul Burton <paulburton@kernel.org>2019-10-23 21:12:49 -0700
commitb42aa3fd5957e4daf4b69129e5ce752a2a53e7d6 (patch)
treed3c9a52925d9a46a1cec14c1f6c0a7aafc25c3e3 /.mailmap
parente4f5cb1a9b27c0f94ef4f5a0178a3fde2d3d0e9e (diff)
MIPS: tlbex: Fix build_restore_pagemask KScratch restore
build_restore_pagemask() will restore the value of register $1/$at when its restore_scratch argument is non-zero, and aims to do so by filling a branch delay slot. Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier) prior to restoring $1 from a KScratch register, in order to resolve a hazard that can result in stale values of the KScratch register being observed. In particular, P-class CPUs from MIPS with out of order execution pipelines such as the P5600 & P6600 are affected. Unfortunately this EHB instruction was inserted in the branch delay slot causing the MFC0 instruction which performs the restoration to no longer execute along with the branch. The result is that the $1 register isn't actually restored, ie. the TLB refill exception handler clobbers it - which is exactly the problem the EHB is meant to avoid for the P-class CPUs. Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when its mode argument equals refill_scratch, and suffers from the same problem. Fix this by in both cases moving the EHB earlier in the emitted code. There's no reason it needs to immediately precede the MFC0 - it simply needs to be between the MTC0 & MFC0. This bug only affects Cavium Octeon systems which use build_fast_tlb_refill_handler(). Signed-off-by: Paul Burton <paulburton@kernel.org> Fixes: 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") Cc: Dmitry Korotin <dkorotin@wavecomp.com> Cc: stable@vger.kernel.org # v3.15+ Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions