summaryrefslogtreecommitdiff
path: root/arch/x86/math-emu
Commit message (Collapse)AuthorAgeFilesLines
* x86: fix math_emu register frame accessTejun Heo2009-03-164-46/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | commit d315760ffa261c15ff92699ac6f514112543d7ca upstream. do_device_not_available() is the handler for #NM and it declares that it takes a unsigned long and calls math_emu(), which takes a long argument and surprisingly expects the stack frame starting at the zero argument would match struct math_emu_info, which isn't true regardless of configuration in the current code. This patch makes do_device_not_available() take struct pt_regs like other exception handlers and initialize struct math_emu_info with pointer to it and pass pointer to the math_emu_info to math_emulate() like normal C functions do. This way, unless gcc makes a copy of struct pt_regs in do_device_not_available(), the register frame is correctly accessed regardless of kernel configuration or compiler used. This doesn't fix all math_emu problems but it at least gets it somewhat working. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86: math_emu info cleanupTejun Heo2009-03-164-42/+39
| | | | | | | | | | | | | | | | commit ae6af41f5a4841f06eb92bc86ad020ad44ae2a30 upstream. Impact: cleanup * Come on, struct info? s/struct info/struct math_emu_info/ * Use struct pt_regs and kernel_vm86_regs instead of defining its own register frame structure. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86: coding style fixes to arch/x86/math-emu/reg_constantPaolo Ciarrocchi2008-06-181-4/+4
| | | | | | | | | | | | | | | | | | | | Before: total: 6 errors, 1 warnings, 117 lines checked After: total: 0 errors, 1 warnings, 117 lines checked paolo@paolo-desktop:~/linux.trees.git$ md5sum /tmp/reg_constant.o.* 780388a3056d58fb759efaf190d5d3d1 /tmp/reg_constant.o.after 780388a3056d58fb759efaf190d5d3d1 /tmp/reg_constant.o.before paolo@paolo-desktop:~/linux.trees.git$ size /tmp/reg_constant.o.* text data bss dec hex filename 457 0 0 457 1c9 /tmp/reg_constant.o.after 457 0 0 457 1c9 /tmp/reg_constant.o.before Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix broken math-emu with lazy allocation of fpu areaSuresh Siddha2008-06-041-5/+8
| | | | | | | | | | | | | | 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, fpu: split FPU state from task struct - v5Suresh Siddha2008-04-193-17/+17
| | | | | | | | | | | | | | | | | | | 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>
* i386: arch/x86/math-emu/reg_ld_str.c: fix warningAndrew Morton2008-04-171-9/+4
| | | | | | | | | | | | arch/x86/math-emu/reg_ld_str.c:380: warning: 'l[0]' may be used uninitialized in this function arch/x86/math-emu/reg_ld_str.c:380: warning: 'l[1]' may be used uninitialized in this function I can't actually spot the bug here. There's one obvious place, but fixing that didn't shut the warning up. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* i386: arch/x86/math-emu/fpu_entry.c warning fixAndrew Morton2008-04-171-0/+1
| | | | | | | | | | | arch/x86/math-emu/fpu_entry.c:555: warning: 'entry_sel_off.empty' is used uninitialized in this function Presumably it's harmless, but I'll sleep better at night knowing that we initialised it. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: arch/x86/math-emu/errors.c: fix printk warningsAndrew Morton2008-01-301-2/+2
| | | | | | | | | | | | arch/x86/math-emu/errors.c:163: warning: format '%ld' expects type 'long int', but argument 3 has type 'u32' arch/x86/math-emu/errors.c:175: warning: format '%ld' expects type 'long int', but argument 3 has type 'u32' arch/x86/math-emu/errors.c:175: warning: format '%ld' expects type 'long int', but argument 4 has type 'u32' arch/x86/math-emu/errors.c:175: warning: format '%ld' expects type 'long int', but argument 5 has type 'u32' arch/x86/math-emu/errors.c:175: warning: format '%ld' expects type 'long int', but argument 6 has type 'u32' Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: x86 user_regset cleanupRoland McGrath2008-01-301-14/+0
| | | | | | | | | 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 user_regset math_emuRoland McGrath2008-01-301-32/+54
| | | | | | | | | | | | | This converts the ptrace/signal accessors for i387 math_emu state to the user_regset interface style, and calls these from the old interfaces. It also cleans up math_emulate's ptrace check to be a single-step check, which is what it really wants. 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: lindent arch/i386/math-emu, cleanupIngo Molnar2008-01-3014-101/+101
| | | | | | | | | manually clean up some of the damage that lindent caused. (this is a separate commit so that in the unlikely case of a typo we can bisect it down to the manual edits.) Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: lindent arch/i386/math-emuIngo Molnar2008-01-3027-6764/+6046
| | | | | | | | | | | | | | | | | | | | | | | | | | | | lindent these files: errors lines of code errors/KLOC arch/x86/math-emu/ 2236 9424 237.2 arch/x86/math-emu/ 128 8706 14.7 no other changes. No code changed: text data bss dec hex filename 5589802 612739 3833856 10036397 9924ad vmlinux.before 5589802 612739 3833856 10036397 9924ad vmlinux.after the intent of this patch is to ease the automated tracking of kernel code quality - it's just much easier for us to maintain it if every file in arch/x86 is supposed to be clean. NOTE: it is a known problem of lindent that it causes some style damage of its own, but it's a safe tool (well, except for the gcc array range initializers extension), so we did the bulk of the changes via lindent, and did the manual fixups in a followup patch. the resulting math-emu code has been tested by Thomas Gleixner on a real 386 DX CPU as well, and it works fine. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* kbuild: fix up CFLAGS usageSam Ravnborg2007-10-141-2/+1
| | | | | | | | | Only in very rare cases is it needed to change CFLAGS outside of arch/*/Makefile. Fix up all wrong cases - in most cases the use of EXTRA_CFLAGS is the only thing needed. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* i386: move math-emuThomas Gleixner2007-10-1147-0/+13419
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>