aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/i387.c
Commit message (Collapse)AuthorAge
* x86: fix broken math-emu with lazy allocation of fpu areaSuresh Siddha2008-06-04
| | | | | | | | | | | | | | Fix the math emulation that got broken with the recent lazy allocation of FPU area. init_fpu() need to be added for the math-emulation path aswell for the FPU area allocation. math emulation enabled kernel booted fine with this, in the presence of "no387 nofxsr" boot param. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: hpa@zytor.com Cc: mingo@elte.hu Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: fix fpu restore from sig returnSuresh Siddha2008-05-10
| | | | | | | | | | | | If the task never used fpu, initialize the fpu before restoring the FP state from the signal handler context. This will allocate the fpu state, if the task never needed it before. Reported-and-bisected-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Tested-by: Eric Sesterhenn <snakebyte@gmx.de> Cc: Frederik Deweerdt <deweerdt@free.fr> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86, fpu: lazy allocation of FPU area - v5Suresh Siddha2008-04-19
| | | | | | | | | | | | | Only allocate the FPU area when the application actually uses FPU, i.e., in the first lazy FPU trap. This could save memory for non-fpu using apps. for example: on my system after boot, there are around 300 processes, with only 17 using FPU. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86, fpu: split FPU state from task struct - v5Suresh Siddha2008-04-19
| | | | | | | | | | | | | | | | | | | Split the FPU save area from the task struct. This allows easy migration of FPU context, and it's generally cleaner. It also allows the following two optimizations: 1) only allocate when the application actually uses FPU, so in the first lazy FPU trap. This could save memory for non-fpu using apps. Next patch does this lazy allocation. 2) allocate the right size for the actual cpu rather than 512 bytes always. Patches enabling xsave/xrstor support (coming shortly) will take advantage of this. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: clean up i387.cIngo Molnar2008-04-17
| | | | | | | | | | | | | | | | | | | | | | | minor coding style cleanups. Before: total: 0 errors, 3 warnings, 479 lines checked After: total: 0 errors, 1 warnings, 483 lines checked No code changed: arch/x86/kernel/i387.o: text data bss dec hex filename 2379 4 8 2391 957 i387.o.before 2379 4 8 2391 957 i387.o.after md5: e1434553a3b4ff1f52ad97a68b1fad8a i387.o.before.asm e1434553a3b4ff1f52ad97a68b1fad8a i387.o.after.asm Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix merge mistake in i387.cJan Beulich2008-03-07
| | | | | | | | | | | | | | | | | | | | convert_fxsr_to_user() in 2.6.24's i387_32.c did this, and convert_to_fxsr() also does the inverse, so I assume it's an oversight that it is no longer being done. [ mingo@elte.hu: we encode it this way because there's no space for the 'FPU Last Instruction Opcode' (->fop) field in the legacy user_i387_ia32_struct that PTRACE_GETFPREGS/PTRACE_SETFPREGS uses. it's probably pure legacy - i'd be surprised if any user-space relied on the FPU Last Opcode in any way. But indeed we used to do it previously so the most conservative thing is to preserve that piece of information. ] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86, i387: fix ptrace leakage using init_fpu()Suresh Siddha2008-03-04
| | | | | | | | | | | | | | | | | | | | | This bug got introduced by the recent i387 merge: commit 4421011120b2304e5c248ae4165a2704588aedf1 Author: Roland McGrath <roland@redhat.com> Date: Wed Jan 30 13:31:50 2008 +0100 x86: x86 i387 user_regset Current usage of unlazy_fpu() in ptrace specific routines is wrong. unlazy_fpu() will not init fpu if the task never used math. So the ptrace calls can expose the parent tasks FPU data in some cases. Replace it with the init_fpu() which will init the math state, if the task never used math before. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de>
* x86: make mxcsr_feature_mask static againAdrian Bunk2008-02-19
| | | | | | | | Signed-off-by: Adrian Bunk <bunk@kernel.org> Cc: Roland McGrath <roland@redhat.com> Cc: hpa@zytor.com Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: x86 user_regset cleanupRoland McGrath2008-01-30
| | | | | | | | | This removes a bunch of dead code that is no longer needed now that the user_regset interfaces are being used for all these jobs. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: x86 i387 user_regsetRoland McGrath2008-01-30
| | | | | | | | | | | | | | | This revamps the i387 code to be shared across 32-bit, 64-bit, and 32-on-64. It does so by consolidating the code in one place based on the user_regset accessor interfaces. This switches 32-bit to using the i387_64.h header and 64-bit to using the i387.c that was previously i387_32.c, but that's what took the least cleanup in each file. Here i387.h is stubbed to always include i387_64.h rather than renaming the file, to keep this diff smaller and easier to read. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: i387 renamingRoland McGrath2008-01-30
This renames arch/x86/kernel/{i387_32.c => i387.c}. This is a pure renaming, but paves the way for merging the 32-bit and 64-bit versions of this code. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>