diff options
author | Suresh Siddha <suresh.b.siddha@intel.com> | 2008-06-02 15:57:27 -0700 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2008-06-04 16:21:24 +0200 |
commit | 870568b39064cab2dd971fe57969916036982862 (patch) | |
tree | 7cbf09a9334642c8bd8eb5cd73044a69928b7755 /arch/x86/mm/ioremap.c | |
parent | cd76374e9de4501acc74f833dc6cb5e7a5dca115 (diff) |
x86, fpu: fix CONFIG_PREEMPT=y corruption of application's FPU stack
Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT,
and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU
optimization".
Add tsk_used_math() checks to prevent calling math_state_restore()
which can sleep in the case of !tsk_used_math(). This prevents
making a blocking call in __switch_to().
Apparently "fpu_counter > 5" check is not enough, as in some signal handling
and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible.
It's a side effect though. This is the failing scenario:
process 'A' in save_i387_ia32() just after clear_used_math()
Got an interrupt and pre-empted out.
At the next context switch to process 'A' again, kernel tries to restore
the math state proactively and sees a fpu_counter > 0 and !tsk_used_math()
This results in init_fpu() during the __switch_to()'s math_state_restore()
And resulting in fpu corruption which will be saved/restored
(save_i387_fxsave and restore_i387_fxsave) during the remaining
part of the signal handling after the context switch.
Bisected-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Diffstat (limited to 'arch/x86/mm/ioremap.c')
0 files changed, 0 insertions, 0 deletions