Skip to contentSkip to conversation

Patch "powerpc/64s: Initialize ISAv3 MMU registers before setting partition table" has been added to the 4.9-stable tree

PATCH [email protected] 1 participant 1 message Dec 11, 2017

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

powerpc/64s: Initialize ISAv3 MMU registers before setting partition table

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 371b80447ff33ddac392c189cf884a5a3e18faeb Mon Sep 17 00:00:00 2001

From: Nicholas Piggin <[email protected]>
Date: Wed, 6 Dec 2017 18:21:14 +1000
Subject: powerpc/64s: Initialize ISAv3 MMU registers before setting partition table

From: Nicholas Piggin <[email protected]>

commit 371b80447ff33ddac392c189cf884a5a3e18faeb upstream.

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")
---
 arch/powerpc/kernel/cpu_setup_power.S |    2 ++
 1 file changed, 2 insertions(+)
arch/powerpc/kernel/cpu_setup_power.S +2 -0
@@ -97,6 +97,7 @@ _GLOBAL(__setup_cpu_power9)
 	beqlr
 	li	r0,0
 	mtspr	SPRN_LPID,r0
+	mtspr	SPRN_PID,r0
 	mfspr	r3,SPRN_LPCR
 	LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
 	or	r3, r3, r4
@@ -119,6 +120,7 @@ _GLOBAL(__restore_cpu_power9)
 	beqlr
 	li	r0,0
 	mtspr	SPRN_LPID,r0
+	mtspr	SPRN_PID,r0
 	mfspr   r3,SPRN_LPCR
 	LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
 	or	r3, r3, r4

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch