| Message ID | |
|---|---|
| State | Accepted |
| Delegated to: | Ralf Baechle |
| Headers | show |
Index: linux-sfr-test/arch/mips/kernel/ptrace.c =================================================================== --- linux-sfr-test.orig/arch/mips/kernel/ptrace.c :40: +0100 +++ linux-sfr-test/arch/mips/kernel/ptrace.c :33: +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);
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 <> Cc: # 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