summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorSuresh Siddha <suresh.b.siddha@intel.com>2009-04-09 15:24:34 -0700
committerH. Peter Anvin <hpa@linux.intel.com>2009-04-20 14:33:00 -0700
commit06c38d5e36b12d040839ff224e805146c0368556 (patch)
tree3f4cbb95319fd7b113cb1b88df7c5ee2d416a948 /.mailmap
parentfc61e6636d13eb3a23eb29b4327eeee9de0ef3bc (diff)
x86-64: fix FPU corruption with signals and preemption
In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: <stable@kernel.org> [2.6.28.x, 2.6.29.x] Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions