Fix a floating-point context restoration regression introduced with
commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling")
that causes a Floating Point exception and consequently a kernel oops
with hard float configurations when one or more FCSR Enable and their
corresponding Cause bits are set both at a time via a ptrace(2) call.
To do so reinstate Cause bit masking originally introduced with commit
b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause bits") to
address this exact problem and then inadvertently removed from the
PTRACE_SETFPREGS request with the commit referred above.
Signed-off-by: Maciej W. Rozycki <macro@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx # v4.0+
---
Hi,
I have verified it with GDB to correctly address the problem.
I guess I must have missed it, because it doesn't trigger with soft float
configurations, where our FP emulator does the right thing, that is
delivers a SIGFPE to the tracee when its execution is resumed. As this
mimics what a CTC1 instruction invoked by the tracee to write the same
value would do and we should allow a debugger to reproduce all the
register access actions a tracee can make I think eventually we ought to
correct context restoration code instead to deliver a SIGFPE with hard
float configurations as well. But for the time being just strictly revert
the incorrect change to make the regression go away.
Therefore, please apply.
Maciej
linux-mips-ptrace-fcsr-all-x.diff
Index: linux-sfr-test/arch/mips/kernel/ptrace.c
===================================================================
--- linux-sfr-test.orig/arch/mips/kernel/ptrace.c 2016-05-12 00:40:11.579182000 +0100
+++ linux-sfr-test/arch/mips/kernel/ptrace.c 2016-05-12 02:33:36.379981000 +0100
@@ -176,6 +176,7 @@ int ptrace_setfpregs(struct task_struct
}
__get_user(value, data + 64);
+ value &= ~FPU_CSR_ALL_X;
fcr31 = child->thread.fpu.fcr31;
mask = boot_cpu_data.fpu_msk31;
child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
