2008-01-30 05:31:51 -07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1994 Linus Torvalds
|
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* General FPU state handling cleanups
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
* x86-64 work by Andi Kleen 2002
|
|
|
|
*/
|
|
|
|
|
2008-10-22 23:26:29 -06:00
|
|
|
#ifndef _ASM_X86_I387_H
|
|
|
|
#define _ASM_X86_I387_H
|
2008-01-30 05:31:51 -07:00
|
|
|
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/kernel_stat.h>
|
|
|
|
#include <linux/regset.h>
|
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:
##################################################################
BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:
Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================
Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.
Suresh wrote:
These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.
This is the code sequence that is probably causing this problem:
a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()
b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.
c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.
d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.
e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()
Now:
1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.
2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.
3) This was working before the fpu changes, because its a spurious
math fault which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.
With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).
This is the failing scenario that existed even before the lazy fpu allocation
changes:
0. CPU's TS flag is set
1. kernel using FPU in some optimized copy routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()
2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.
3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts
4. We complete the padlock routine
5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.
6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.
This causes the fpu leakage.
Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-13 06:02:26 -06:00
|
|
|
#include <linux/hardirq.h>
|
2008-02-04 08:47:58 -07:00
|
|
|
#include <asm/asm.h>
|
2008-01-30 05:31:51 -07:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/sigcontext.h>
|
|
|
|
#include <asm/user.h>
|
|
|
|
#include <asm/uaccess.h>
|
2008-07-29 11:29:19 -06:00
|
|
|
#include <asm/xsave.h>
|
2008-01-30 05:31:51 -07:00
|
|
|
|
2008-07-29 11:29:21 -06:00
|
|
|
extern unsigned int sig_xstate_size;
|
2008-01-30 05:31:51 -07:00
|
|
|
extern void fpu_init(void);
|
|
|
|
extern void mxcsr_feature_mask_init(void);
|
2008-03-10 16:28:05 -06:00
|
|
|
extern int init_fpu(struct task_struct *child);
|
2008-01-30 05:31:51 -07:00
|
|
|
extern asmlinkage void math_state_restore(void);
|
2009-04-24 01:40:59 -06:00
|
|
|
extern void __math_state_restore(void);
|
2008-03-10 16:28:04 -06:00
|
|
|
extern void init_thread_xstate(void);
|
2008-07-21 11:01:57 -06:00
|
|
|
extern int dump_fpu(struct pt_regs *, struct user_i387_struct *);
|
2008-01-30 05:31:51 -07:00
|
|
|
|
|
|
|
extern user_regset_active_fn fpregs_active, xfpregs_active;
|
|
|
|
extern user_regset_get_fn fpregs_get, xfpregs_get, fpregs_soft_get;
|
|
|
|
extern user_regset_set_fn fpregs_set, xfpregs_set, fpregs_soft_set;
|
|
|
|
|
2008-07-29 11:29:25 -06:00
|
|
|
extern struct _fpx_sw_bytes fx_sw_reserved;
|
2008-01-30 05:31:51 -07:00
|
|
|
#ifdef CONFIG_IA32_EMULATION
|
2008-07-29 11:29:21 -06:00
|
|
|
extern unsigned int sig_xstate_ia32_size;
|
2008-07-29 11:29:25 -06:00
|
|
|
extern struct _fpx_sw_bytes fx_sw_reserved_ia32;
|
2008-01-30 05:31:51 -07:00
|
|
|
struct _fpstate_ia32;
|
2008-07-29 11:29:22 -06:00
|
|
|
struct _xstate_ia32;
|
|
|
|
extern int save_i387_xstate_ia32(void __user *buf);
|
|
|
|
extern int restore_i387_xstate_ia32(void __user *buf);
|
2008-01-30 05:31:51 -07:00
|
|
|
#endif
|
|
|
|
|
2008-07-29 11:29:20 -06:00
|
|
|
#define X87_FSW_ES (1 << 7) /* Exception Summary */
|
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
|
|
|
|
/* Ignore delayed exceptions from user space */
|
|
|
|
static inline void tolerant_fwait(void)
|
|
|
|
{
|
|
|
|
asm volatile("1: fwait\n"
|
|
|
|
"2:\n"
|
2008-03-23 02:02:18 -06:00
|
|
|
_ASM_EXTABLE(1b, 2b));
|
2008-01-30 05:31:51 -07:00
|
|
|
}
|
|
|
|
|
2008-07-29 11:29:20 -06:00
|
|
|
static inline int fxrstor_checking(struct i387_fxsave_struct *fx)
|
2008-01-30 05:31:51 -07:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
asm volatile("1: rex64/fxrstor (%[fx])\n\t"
|
|
|
|
"2:\n"
|
|
|
|
".section .fixup,\"ax\"\n"
|
|
|
|
"3: movl $-1,%[err]\n"
|
|
|
|
" jmp 2b\n"
|
|
|
|
".previous\n"
|
2008-03-23 02:02:18 -06:00
|
|
|
_ASM_EXTABLE(1b, 3b)
|
2008-01-30 05:31:51 -07:00
|
|
|
: [err] "=r" (err)
|
2009-04-08 05:32:00 -06:00
|
|
|
#if 0 /* See comment in fxsave() below. */
|
2008-01-30 05:31:51 -07:00
|
|
|
: [fx] "r" (fx), "m" (*fx), "0" (0));
|
|
|
|
#else
|
|
|
|
: [fx] "cdaSDb" (fx), "m" (*fx), "0" (0));
|
|
|
|
#endif
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
|
|
|
|
is pending. Clear the x87 state here by setting it to fixed
|
|
|
|
values. The kernel data segment can be sometimes 0 and sometimes
|
|
|
|
new user value. Both should be ok.
|
|
|
|
Use the PDA as safe address because it should be already in L1. */
|
2008-07-29 11:29:20 -06:00
|
|
|
static inline void clear_fpu_state(struct task_struct *tsk)
|
2008-01-30 05:31:51 -07:00
|
|
|
{
|
2008-07-29 11:29:20 -06:00
|
|
|
struct xsave_struct *xstate = &tsk->thread.xstate->xsave;
|
|
|
|
struct i387_fxsave_struct *fx = &tsk->thread.xstate->fxsave;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xsave header may indicate the init state of the FP.
|
|
|
|
*/
|
|
|
|
if ((task_thread_info(tsk)->status & TS_XSAVE) &&
|
|
|
|
!(xstate->xsave_hdr.xstate_bv & XSTATE_FP))
|
|
|
|
return;
|
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
if (unlikely(fx->swd & X87_FSW_ES))
|
2008-03-23 02:02:18 -06:00
|
|
|
asm volatile("fnclex");
|
2008-01-30 05:31:51 -07:00
|
|
|
alternative_input(ASM_NOP8 ASM_NOP2,
|
2008-03-23 02:02:18 -06:00
|
|
|
" emms\n" /* clear stack tags */
|
|
|
|
" fildl %%gs:0", /* load to clear state */
|
|
|
|
X86_FEATURE_FXSAVE_LEAK);
|
2008-01-30 05:31:51 -07:00
|
|
|
}
|
|
|
|
|
2008-07-29 11:29:25 -06:00
|
|
|
static inline int fxsave_user(struct i387_fxsave_struct __user *fx)
|
2008-01-30 05:31:51 -07:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
asm volatile("1: rex64/fxsave (%[fx])\n\t"
|
|
|
|
"2:\n"
|
|
|
|
".section .fixup,\"ax\"\n"
|
|
|
|
"3: movl $-1,%[err]\n"
|
|
|
|
" jmp 2b\n"
|
|
|
|
".previous\n"
|
2008-03-23 02:02:18 -06:00
|
|
|
_ASM_EXTABLE(1b, 3b)
|
2008-01-30 05:31:51 -07:00
|
|
|
: [err] "=r" (err), "=m" (*fx)
|
2009-04-08 05:32:00 -06:00
|
|
|
#if 0 /* See comment in fxsave() below. */
|
2008-01-30 05:31:51 -07:00
|
|
|
: [fx] "r" (fx), "0" (0));
|
|
|
|
#else
|
|
|
|
: [fx] "cdaSDb" (fx), "0" (0));
|
|
|
|
#endif
|
2008-03-23 02:02:18 -06:00
|
|
|
if (unlikely(err) &&
|
|
|
|
__clear_user(fx, sizeof(struct i387_fxsave_struct)))
|
2008-01-30 05:31:51 -07:00
|
|
|
err = -EFAULT;
|
|
|
|
/* No need to clear here because the caller clears USED_MATH */
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2008-07-29 11:29:20 -06:00
|
|
|
static inline void fxsave(struct task_struct *tsk)
|
2008-01-30 05:31:51 -07:00
|
|
|
{
|
|
|
|
/* Using "rex64; fxsave %0" is broken because, if the memory operand
|
|
|
|
uses any extended registers for addressing, a second REX prefix
|
|
|
|
will be generated (to the assembler, rex64 followed by semicolon
|
|
|
|
is a separate instruction), and hence the 64-bitness is lost. */
|
|
|
|
#if 0
|
|
|
|
/* Using "fxsaveq %0" would be the ideal choice, but is only supported
|
|
|
|
starting with gas 2.16. */
|
|
|
|
__asm__ __volatile__("fxsaveq %0"
|
2008-03-10 16:28:04 -06:00
|
|
|
: "=m" (tsk->thread.xstate->fxsave));
|
2008-01-30 05:31:51 -07:00
|
|
|
#elif 0
|
|
|
|
/* Using, as a workaround, the properly prefixed form below isn't
|
|
|
|
accepted by any binutils version so far released, complaining that
|
|
|
|
the same type of prefix is used twice if an extended register is
|
|
|
|
needed for addressing (fix submitted to mainline 2005-11-21). */
|
|
|
|
__asm__ __volatile__("rex64/fxsave %0"
|
2008-03-10 16:28:04 -06:00
|
|
|
: "=m" (tsk->thread.xstate->fxsave));
|
2008-01-30 05:31:51 -07:00
|
|
|
#else
|
|
|
|
/* This, however, we can work around by forcing the compiler to select
|
|
|
|
an addressing mode that doesn't require extended registers. */
|
2008-03-10 16:28:04 -06:00
|
|
|
__asm__ __volatile__("rex64/fxsave (%1)"
|
|
|
|
: "=m" (tsk->thread.xstate->fxsave)
|
|
|
|
: "cdaSDb" (&tsk->thread.xstate->fxsave));
|
2008-01-30 05:31:51 -07:00
|
|
|
#endif
|
2008-07-29 11:29:20 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __save_init_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (task_thread_info(tsk)->status & TS_XSAVE)
|
|
|
|
xsave(tsk);
|
|
|
|
else
|
|
|
|
fxsave(tsk);
|
|
|
|
|
|
|
|
clear_fpu_state(tsk);
|
2008-01-30 05:31:51 -07:00
|
|
|
task_thread_info(tsk)->status &= ~TS_USEDFPU;
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_X86_32 */
|
|
|
|
|
2009-03-04 11:42:27 -07:00
|
|
|
#ifdef CONFIG_MATH_EMULATION
|
|
|
|
extern void finit_task(struct task_struct *tsk);
|
|
|
|
#else
|
|
|
|
static inline void finit_task(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
2008-05-23 17:26:37 -06:00
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
static inline void tolerant_fwait(void)
|
|
|
|
{
|
|
|
|
asm volatile("fnclex ; fwait");
|
|
|
|
}
|
|
|
|
|
2009-04-08 05:31:59 -06:00
|
|
|
/* perform fxrstor iff the processor has extended states, otherwise frstor */
|
|
|
|
static inline int fxrstor_checking(struct i387_fxsave_struct *fx)
|
2008-01-30 05:31:51 -07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The "nop" is needed to make the instructions the same
|
|
|
|
* length.
|
|
|
|
*/
|
|
|
|
alternative_input(
|
|
|
|
"nop ; frstor %1",
|
|
|
|
"fxrstor %1",
|
|
|
|
X86_FEATURE_FXSR,
|
2009-04-08 05:31:59 -06:00
|
|
|
"m" (*fx));
|
|
|
|
|
2009-04-08 05:31:58 -06:00
|
|
|
return 0;
|
2008-01-30 05:31:51 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* We need a safe address that is cheap to find and that is already
|
|
|
|
in L1 during context switch. The best choices are unfortunately
|
|
|
|
different for UP and SMP */
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
#define safe_address (__per_cpu_offset[0])
|
|
|
|
#else
|
|
|
|
#define safe_address (kstat_cpu(0).cpustat.user)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These must be called with preempt disabled
|
|
|
|
*/
|
|
|
|
static inline void __save_init_fpu(struct task_struct *tsk)
|
|
|
|
{
|
2008-07-29 11:29:20 -06:00
|
|
|
if (task_thread_info(tsk)->status & TS_XSAVE) {
|
|
|
|
struct xsave_struct *xstate = &tsk->thread.xstate->xsave;
|
|
|
|
struct i387_fxsave_struct *fx = &tsk->thread.xstate->fxsave;
|
|
|
|
|
|
|
|
xsave(tsk);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xsave header may indicate the init state of the FP.
|
|
|
|
*/
|
|
|
|
if (!(xstate->xsave_hdr.xstate_bv & XSTATE_FP))
|
|
|
|
goto end;
|
|
|
|
|
|
|
|
if (unlikely(fx->swd & X87_FSW_ES))
|
|
|
|
asm volatile("fnclex");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* we can do a simple return here or be paranoid :)
|
|
|
|
*/
|
|
|
|
goto clear_state;
|
|
|
|
}
|
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
/* Use more nops than strictly needed in case the compiler
|
|
|
|
varies code */
|
|
|
|
alternative_input(
|
|
|
|
"fnsave %[fx] ;fwait;" GENERIC_NOP8 GENERIC_NOP4,
|
|
|
|
"fxsave %[fx]\n"
|
|
|
|
"bt $7,%[fsw] ; jnc 1f ; fnclex\n1:",
|
|
|
|
X86_FEATURE_FXSR,
|
2008-03-10 16:28:04 -06:00
|
|
|
[fx] "m" (tsk->thread.xstate->fxsave),
|
|
|
|
[fsw] "m" (tsk->thread.xstate->fxsave.swd) : "memory");
|
2008-07-29 11:29:20 -06:00
|
|
|
clear_state:
|
2008-01-30 05:31:51 -07:00
|
|
|
/* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception
|
|
|
|
is pending. Clear the x87 state here by setting it to fixed
|
|
|
|
values. safe_address is a random variable that should be in L1 */
|
|
|
|
alternative_input(
|
|
|
|
GENERIC_NOP8 GENERIC_NOP2,
|
|
|
|
"emms\n\t" /* clear stack tags */
|
|
|
|
"fildl %[addr]", /* set F?P to defined value */
|
|
|
|
X86_FEATURE_FXSAVE_LEAK,
|
|
|
|
[addr] "m" (safe_address));
|
2008-07-29 11:29:20 -06:00
|
|
|
end:
|
2008-01-30 05:31:51 -07:00
|
|
|
task_thread_info(tsk)->status &= ~TS_USEDFPU;
|
|
|
|
}
|
|
|
|
|
2008-07-29 11:29:22 -06:00
|
|
|
#endif /* CONFIG_X86_64 */
|
|
|
|
|
2009-04-08 05:31:59 -06:00
|
|
|
static inline int restore_fpu_checking(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (task_thread_info(tsk)->status & TS_XSAVE)
|
|
|
|
return xrstor_checking(&tsk->thread.xstate->xsave);
|
|
|
|
else
|
|
|
|
return fxrstor_checking(&tsk->thread.xstate->fxsave);
|
|
|
|
}
|
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
/*
|
|
|
|
* Signal frame handlers...
|
|
|
|
*/
|
2008-07-29 11:29:22 -06:00
|
|
|
extern int save_i387_xstate(void __user *buf);
|
|
|
|
extern int restore_i387_xstate(void __user *buf);
|
2008-01-30 05:31:51 -07:00
|
|
|
|
|
|
|
static inline void __unlazy_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (task_thread_info(tsk)->status & TS_USEDFPU) {
|
|
|
|
__save_init_fpu(tsk);
|
|
|
|
stts();
|
|
|
|
} else
|
|
|
|
tsk->fpu_counter = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __clear_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (task_thread_info(tsk)->status & TS_USEDFPU) {
|
|
|
|
tolerant_fwait();
|
|
|
|
task_thread_info(tsk)->status &= ~TS_USEDFPU;
|
|
|
|
stts();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void kernel_fpu_begin(void)
|
|
|
|
{
|
|
|
|
struct thread_info *me = current_thread_info();
|
|
|
|
preempt_disable();
|
|
|
|
if (me->status & TS_USEDFPU)
|
|
|
|
__save_init_fpu(me->task);
|
|
|
|
else
|
|
|
|
clts();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void kernel_fpu_end(void)
|
|
|
|
{
|
|
|
|
stts();
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2009-08-30 23:11:54 -06:00
|
|
|
static inline bool irq_fpu_usable(void)
|
|
|
|
{
|
|
|
|
struct pt_regs *regs;
|
|
|
|
|
|
|
|
return !in_interrupt() || !(regs = get_irq_regs()) || \
|
|
|
|
user_mode(regs) || (read_cr0() & X86_CR0_TS);
|
|
|
|
}
|
|
|
|
|
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:
##################################################################
BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:
Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================
Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.
Suresh wrote:
These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.
This is the code sequence that is probably causing this problem:
a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()
b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.
c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.
d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.
e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()
Now:
1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.
2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.
3) This was working before the fpu changes, because its a spurious
math fault which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.
With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).
This is the failing scenario that existed even before the lazy fpu allocation
changes:
0. CPU's TS flag is set
1. kernel using FPU in some optimized copy routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()
2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.
3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts
4. We complete the padlock routine
5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.
6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.
This causes the fpu leakage.
Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-13 06:02:26 -06:00
|
|
|
/*
|
|
|
|
* Some instructions like VIA's padlock instructions generate a spurious
|
|
|
|
* DNA fault but don't modify SSE registers. And these instructions
|
2009-06-09 08:40:50 -06:00
|
|
|
* get used from interrupt context as well. To prevent these kernel instructions
|
|
|
|
* in interrupt context interacting wrongly with other user/kernel fpu usage, we
|
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:
##################################################################
BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:
Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================
Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.
Suresh wrote:
These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.
This is the code sequence that is probably causing this problem:
a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()
b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.
c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.
d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.
e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()
Now:
1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.
2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.
3) This was working before the fpu changes, because its a spurious
math fault which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.
With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).
This is the failing scenario that existed even before the lazy fpu allocation
changes:
0. CPU's TS flag is set
1. kernel using FPU in some optimized copy routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()
2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.
3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts
4. We complete the padlock routine
5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.
6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.
This causes the fpu leakage.
Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-13 06:02:26 -06:00
|
|
|
* should use them only in the context of irq_ts_save/restore()
|
|
|
|
*/
|
|
|
|
static inline int irq_ts_save(void)
|
|
|
|
{
|
|
|
|
/*
|
2009-06-09 08:40:50 -06:00
|
|
|
* If in process context and not atomic, we can take a spurious DNA fault.
|
|
|
|
* Otherwise, doing clts() in process context requires disabling preemption
|
|
|
|
* or some heavy lifting like kernel_fpu_begin()
|
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:
##################################################################
BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:
Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================
Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.
Suresh wrote:
These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.
This is the code sequence that is probably causing this problem:
a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()
b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.
c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.
d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.
e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()
Now:
1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.
2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.
3) This was working before the fpu changes, because its a spurious
math fault which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.
With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).
This is the failing scenario that existed even before the lazy fpu allocation
changes:
0. CPU's TS flag is set
1. kernel using FPU in some optimized copy routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()
2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.
3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts
4. We complete the padlock routine
5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.
6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.
This causes the fpu leakage.
Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-13 06:02:26 -06:00
|
|
|
*/
|
2009-06-09 08:40:50 -06:00
|
|
|
if (!in_atomic())
|
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:
##################################################################
BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:
Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================
Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.
Suresh wrote:
These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.
This is the code sequence that is probably causing this problem:
a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()
b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.
c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.
d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.
e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()
Now:
1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.
2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.
3) This was working before the fpu changes, because its a spurious
math fault which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.
With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).
This is the failing scenario that existed even before the lazy fpu allocation
changes:
0. CPU's TS flag is set
1. kernel using FPU in some optimized copy routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()
2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.
3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts
4. We complete the padlock routine
5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.
6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.
This causes the fpu leakage.
Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.
Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-13 06:02:26 -06:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (read_cr0() & X86_CR0_TS) {
|
|
|
|
clts();
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void irq_ts_restore(int TS_state)
|
|
|
|
{
|
|
|
|
if (TS_state)
|
|
|
|
stts();
|
|
|
|
}
|
|
|
|
|
2008-01-30 05:31:51 -07:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
|
|
|
|
static inline void save_init_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
__save_init_fpu(tsk);
|
|
|
|
stts();
|
|
|
|
}
|
|
|
|
|
|
|
|
#define unlazy_fpu __unlazy_fpu
|
|
|
|
#define clear_fpu __clear_fpu
|
|
|
|
|
|
|
|
#else /* CONFIG_X86_32 */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These disable preemption on their own and are safe
|
|
|
|
*/
|
|
|
|
static inline void save_init_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
__save_init_fpu(tsk);
|
|
|
|
stts();
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void unlazy_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
__unlazy_fpu(tsk);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void clear_fpu(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
__clear_fpu(tsk);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_X86_64 */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* i387 state interaction
|
|
|
|
*/
|
|
|
|
static inline unsigned short get_fpu_cwd(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (cpu_has_fxsr) {
|
2008-03-10 16:28:04 -06:00
|
|
|
return tsk->thread.xstate->fxsave.cwd;
|
2008-01-30 05:31:51 -07:00
|
|
|
} else {
|
2008-04-16 02:27:53 -06:00
|
|
|
return (unsigned short)tsk->thread.xstate->fsave.cwd;
|
2008-01-30 05:31:51 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned short get_fpu_swd(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (cpu_has_fxsr) {
|
2008-03-10 16:28:04 -06:00
|
|
|
return tsk->thread.xstate->fxsave.swd;
|
2008-01-30 05:31:51 -07:00
|
|
|
} else {
|
2008-04-16 02:27:53 -06:00
|
|
|
return (unsigned short)tsk->thread.xstate->fsave.swd;
|
2008-01-30 05:31:51 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned short get_fpu_mxcsr(struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
if (cpu_has_xmm) {
|
2008-03-10 16:28:04 -06:00
|
|
|
return tsk->thread.xstate->fxsave.mxcsr;
|
2008-01-30 05:31:51 -07:00
|
|
|
} else {
|
|
|
|
return MXCSR_DEFAULT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-22 23:26:29 -06:00
|
|
|
#endif /* _ASM_X86_I387_H */
|