summaryrefslogtreecommitdiff
path: root/arch/powerpc/xmon
diff options
context:
space:
mode:
authorNicholas Piggin <npiggin@gmail.com>2017-12-06 11:21:14 +0300
committerMichael Ellerman <mpe@ellerman.id.au>2017-12-06 15:32:43 +0300
commit371b80447ff33ddac392c189cf884a5a3e18faeb (patch)
tree8d79b05a1eefebc306f47294a33b6a5a3597e10e /arch/powerpc/xmon
parentab9dbf771ff9b6b7e814e759213ed01d7f0de320 (diff)
downloadlinux-371b80447ff33ddac392c189cf884a5a3e18faeb.tar.xz
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
kexec can leave MMU registers set when booting into a new kernel, the PIDR (Process Identification Register) in particular. The boot sequence does not zero PIDR, so it only gets set when CPUs first switch to a userspace processes (until then it's running a kernel thread with effective PID = 0). This leaves a window where a process table entry and page tables are set up due to user processes running on other CPUs, that happen to match with a stale PID. The CPU with that PID may cause speculative accesses that address quadrant 0 (aka userspace addresses), which will result in cached translations and PWC (Page Walk Cache) for that process, on a CPU which is not in the mm_cpumask and so they will not be invalidated properly. The most common result is the kernel hanging in infinite page fault loops soon after kexec (usually in schedule_tail, which is usually the first non-speculative quadrant 0 access to a new PID) due to a stale PWC. However being a stale translation error, it could result in anything up to security and data corruption problems. Fix this by zeroing out PIDR at boot and kexec. Fixes: 7e381c0ff618 ("powerpc/mm/radix: Add mmu context handling callback for radix") Cc: stable@vger.kernel.org # v4.7+ Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'arch/powerpc/xmon')
0 files changed, 0 insertions, 0 deletions