This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix masking of SRR1 bits on instruction fault
to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From 475b581ff57bc01437cbc680e281869918447763 Mon Sep 17 00:00:00 2001
From: Michael Ellerman mpe@ellerman.id.au Date: Tue, 14 Nov 2017 15:48:47 +1100 Subject: powerpc/64s: Fix masking of SRR1 bits on instruction fault
From: Michael Ellerman mpe@ellerman.id.au
commit 475b581ff57bc01437cbc680e281869918447763 upstream.
On 64-bit Book3s, when we take an instruction fault the reason for the fault may be reported in SRR1. For data faults the reason is reported in DSISR (Data Storage Instruction Status Register).
The reasons reported in each do not necessarily correspond, so we mask the SRR1 bits before copying them to the DSISR, which is then used by the page fault code.
Prior to commit b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") we used a hard-coded mask of 0x58200000, which corresponds to:
DSISR_NOHPTE 0x40000000 /* no translation found */ DSISR_NOEXEC_OR_G 0x10000000 /* exec of no-exec or guarded */ DSISR_PROTFAULT 0x08000000 /* protection fault */ DSISR_KEYFAULT 0x00200000 /* Storage Key fault */
That commit added a #define for the mask, DSISR_SRR1_MATCH_64S, but incorrectly used a different similarly named DSISR_BAD_FAULT_64S.
This had the effect of changing the mask to 0xa43a0000, which omits everything but DSISR_KEYFAULT.
Luckily this had no visible effect, because in practice we hardly use the DSISR bits. The lack of DSISR_NOHPTE means a TLB flush optimisation was missed in the native HPTE code, and DSISR_NOEXEC_OR_G and DSISR_PROTFAULT are both only used to trigger rare warnings.
So we got lucky, but let's fix it. The new value only has bits between 17 and 30 set, so we can continue to use andis.
Fixes: b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") Signed-off-by: Michael Ellerman mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/powerpc/kernel/exceptions-64s.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -542,7 +542,7 @@ EXC_COMMON_BEGIN(instruction_access_comm RECONCILE_IRQ_STATE(r10, r11) ld r12,_MSR(r1) ld r3,_NIP(r1) - andis. r4,r12,DSISR_BAD_FAULT_64S@h + andis. r4,r12,DSISR_SRR1_MATCH_64S@h li r5,0x400 std r3,_DAR(r1) std r4,_DSISR(r1)
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch