Bug in the _save_fp_context.
I posted the following problem on the list almost a year ago, but it still hasn't made into the SGI CVS.
I think there is a bug in the _save_fp_context function in arch/mips/kernel/r4k_fpu.S
The problem is the following piece of code:
jr ra
.set nomacro
EX(sw t0,SC_FPC_EIR(a0))
.set macro
We do not handle entries in the __ex_table which is located in a branch delay.
So we need to handle the situation where we take a page fault on an instruction which is located in a brach delay slot, or we don't put the "potential" faulting instruction in a delay slot.
This situation probably doesn't generally hit people since it hasn't been fix yet, but if you try run something nasty like Crashme, you will get hit by this problem.
I suggest the following patch.
/Carsten
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Index: arch/mips/kernel/r4k_fpu.S
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/r4k_fpu.S,v
retrieving revision 1.12
mips/kernel/r4k_fpu.S +2 -3
@@ -50,11 +50,10 @@ EX(sdc1 $f30,(SC_FPREGS+240)(a0)) EX(sw t1,SC_FPC_CSR(a0)) cfc1 t0,$0 # implementation/version + EX(sw t0,SC_FPC_EIR(a0)) jr ra - .set nomacro - EX(sw t0,SC_FPC_EIR(a0)) - .set macro + nop END(_save_fp_context) /*
Quoted 56 lines · H . J . Lu
Quoted 55 lines · Carsten Langgaard
I posted the following problem on the list almost a year ago, but it still hasn't made into the SGI CVS.
I think there is a bug in the_save_fp_contextfunction inarch/mips/kernel/r4k_fpu.SThe problem is the following piece of code:
jr ra
.set nomacro
EX(sw t0,SC_FPC_EIR(a0))
.set macroWe do not handle entries in the
__ex_tablewhich is located in a branch delay.
So we need to handle the situation where we take a page fault on an instruction which is located in a brach delay slot, or we don't put the "potential" faulting instruction in a delay slot.This situation probably doesn't generally hit people since it hasn't been fix yet, but if you try run something nasty like Crashme, you will get hit by this problem.
I suggest the following patch./Carsten
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.comIndex:
arch/mips/kernel/r4k_fpu.S
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/r4k_fpu.S,v
retrieving revision 1.12
diff -u -r1.12r4k_fpu.Smips/kernel/r4k_fpu.S 2002/01/17 14:21:09 renamed from mips/kernel/r4k_fpu.S 2001/04/11 05:19:46 1.12 +2
-3@@ -50,11 +50,10 @@ EX(sdc1 $f30,(SC_FPREGS+240)(a0)) EX(sw t1,SC_FPC_CSR(a0)) cfc1 t0,$0 # implementation/version + EX(sw t0,SC_FPC_EIR(a0)) jr ra - .set nomacro - EX(sw t0,SC_FPC_EIR(a0)) - .set macro + nop END(_save_fp_context)
Quoted 5 lines
mips/kernel/r4k_fpu.S 2002/01/17 14:21:09 line 59
Quoted 1 line
mips/kernel/r4k_fpu.S 2002/01/17 14:21:09 renamed from mips/kernel/r4k_fpu.S 2001/04/11 05:19:46 1.12 +0
-0/*Do we still need this patch for 2.4 on OSS?
H.J.
No, this fix is not needed any more, as we now handle entries in the __ex_table which is located in a branch delay.