1. 19 5月, 2015 15 次提交
    • I
      x86/fpu: Move i387.c and xsave.c to arch/x86/kernel/fpu/ · ce4c4c26
      Ingo Molnar 提交于
      Create a new subdirectory for the FPU support code in arch/x86/kernel/fpu/.
      
      Rename 'i387.c' to 'core.c' - as this really collects the core FPU support
      code, nothing i387 specific.
      
      We'll better organize this directory in later patches.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ce4c4c26
    • I
      x86/fpu: Rename init_thread_xstate() to fpstate_xstate_init_size() · 3f6a0bce
      Ingo Molnar 提交于
      So init_thread_xstate() is a misnomer in that it's not really related to a specific
      thread - it determines, once during initial bootup, the size of the xstate context.
      
      Also improve the comments.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3f6a0bce
    • I
      x86/fpu: Rename fpu_init() to fpu__cpu_init() · 3a9c4b0d
      Ingo Molnar 提交于
      fpu_init() is a bit of a misnomer in that it (falsely) creates the
      impression that it's related to the (old) fpu_finit() function,
      which initializes FPU ctx state.
      
      Rename it to fpu__cpu_init() to make its boot time initialization
      clear, and to move it to the fpu__*() namespace.
      
      Also fix and extend its comment block to point out that it's
      called not only on the boot CPU, but on secondary CPUs as well.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3a9c4b0d
    • I
      x86/fpu: Rename fpu_finit() to fpstate_init() · c0ee2cf6
      Ingo Molnar 提交于
      Make it clear that we are initializing the in-memory FPU context area,
      no the FPU registers.
      
      Also move it to the fpu__*() namespace.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c0ee2cf6
    • I
      x86/fpu: Rename fpu_alloc() to fpstate_alloc() · ed97b085
      Ingo Molnar 提交于
      Use the fpu__*() namespace for fpstate_alloc() as well.
      
      Also add a comment about FPU state alignment.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ed97b085
    • I
      x86/fpu: Move fpu_alloc() out of line · 6fbe6712
      Ingo Molnar 提交于
      This is not a small function, and it's used in several places,
      one of them a popular module (KVM).
      
      Move the function out of line. This saves a bit of text,
      even with the symbol export overhead:
      
         text    data     bss     dec     hex filename
         12566052        1619504 1089536 15275092         e91454 vmlinux.before
         12566046        1619504 1089536 15275086         e9144e vmlinux.after
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      6fbe6712
    • I
      x86/fpu: Simplify fpu__unlazy_stopped() · 071ae621
      Ingo Molnar 提交于
      Open code the PF_USED_MATH logic, to make the logic more obvious.
      
      (We'll slowly convert the other users of *_used_math() methods as well.)
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      071ae621
    • I
      x86/fpu: Optimize fpu__unlazy_stopped() · 8694c3e7
      Ingo Molnar 提交于
      This function is only called for stopped child tasks, so the
      fpu__save() branch will never get called - remove it.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      8694c3e7
    • I
      x86/fpu: Rename init_fpu() to fpu__unlazy_stopped() and add debugging check · 67e97fc2
      Ingo Molnar 提交于
      This function name is a misnomer now that we've split out all the
      other users from it. Rename it accordingly: it's used to save
      the FPU state of (ptrace-)stopped child tasks.
      
      Add debugging check to double check this intended usage: that this
      function is only called for non-current, stopped child tasks.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      67e97fc2
    • I
      x86/fpu: Make init_fpu() static · bda28379
      Ingo Molnar 提交于
      Now that the allocation users have been split off into a separate
      function, init_fpu() has become local to i387.c: make it static.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      bda28379
    • I
      x86/fpu: Split an fpstate_alloc_init() function out of init_fpu() · 97185c95
      Ingo Molnar 提交于
      Most init_fpu() users don't want the register-saving aspect of the
      function, they are calling it for 'current' and when FPU registers
      are not allocated and initialized yet.
      
      Split out a simplified API that does just that (and add debug-checks
      for these conditions): fpstate_alloc_init().
      
      Use it where appropriate.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      97185c95
    • I
      x86/fpu: Rename fpu_detect() to fpu__detect() · 1a7dc0db
      Ingo Molnar 提交于
      Use the fpu__*() namespace to organize FPU ops better.
      
      Also document fpu__detect() a bit.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1a7dc0db
    • I
      x86/fpu: Add debugging check to fpu__save() · 87cdb98a
      Ingo Molnar 提交于
      Document the function a bit more and add debugging check that we are only
      running this with the current task.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      87cdb98a
    • I
      x86/fpu: Add comments to fpu__save() and restrict its export · 4af08f2f
      Ingo Molnar 提交于
      Add an explanation to fpu__save() and also don't export it to
      random modules - we don't want them to futz around with deep kernel
      internals.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4af08f2f
    • I
      x86/fpu: Rename unlazy_fpu() to fpu__save() · 0a781551
      Ingo Molnar 提交于
      This function is a misnomer on two levels:
      
      1) it doesn't really manipulate TS on modern CPUs anymore, its
         primary purpose is to save FPU state, used:
      
            - when executing fork()/clone(): to copy current FPU state
              to the child's FPU state.
      
            - when handling math exceptions: to generate the math error
              si_code in the signal frame.
      
      2) even on legacy CPUs it doesn't actually 'unlazy', if then
         it lazies the FPU state: as a side effect of the old FNSAVE
         instruction which clears (destroys) FPU state it's necessary
         to set CR0::TS.
      
      So rename it to fpu__save() to better reflect its purpose.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      0a781551
  2. 17 4月, 2015 1 次提交
    • B
      x86/fpu: Load xsave pointer *after* initialization · 18ecb3bf
      Borislav Petkov 提交于
      So I was playing with gdb today and did this simple thing:
      
      	gdb /bin/ls
      
      	...
      
      	(gdb) run
      
      Box exploded with this splat:
      
      	BUG: unable to handle kernel NULL pointer dereference at 00000000000001d0
      	IP: [<ffffffff8100fe5a>] xstateregs_get+0x7a/0x120
      	[...]
      
      	Call Trace:
      	 ptrace_regset
      	 ptrace_request
      	 ? wait_task_inactive
      	 ? preempt_count_sub
      	 arch_ptrace
      	 ? ptrace_get_task_struct
      	 SyS_ptrace
      	 system_call_fastpath
      
      ... because we do cache &target->thread.fpu.state->xsave into the
      local variable xsave but that pointer is NULL at that time and
      it gets initialized later, in init_fpu(), see:
      
      	e7f180dc ("x86/fpu: Change xstateregs_get()/set() to use ->xsave.i387 rather than ->fxsave")
      
      The fix is simple: load xsave *after* init_fpu() has run.
      
      Also do the same in xstateregs_set(), as suggested by Oleg Nesterov.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Tavis Ormandy <taviso@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1429209697-5902-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      18ecb3bf
  3. 23 3月, 2015 2 次提交
  4. 10 3月, 2015 2 次提交
  5. 23 2月, 2015 2 次提交
  6. 19 2月, 2015 3 次提交
  7. 04 2月, 2015 1 次提交
  8. 20 1月, 2015 3 次提交
    • O
      x86, fpu: Fix math_state_restore() race with kernel_fpu_begin() · 7575637a
      Oleg Nesterov 提交于
      math_state_restore() can race with kernel_fpu_begin() if irq comes
      right after __thread_fpu_begin(), __save_init_fpu() will overwrite
      fpu->state we are going to restore.
      
      Add 2 simple helpers, kernel_fpu_disable() and kernel_fpu_enable()
      which simply set/clear in_kernel_fpu, and change math_state_restore()
      to exclude kernel_fpu_begin() in between.
      
      Alternatively we could use local_irq_save/restore, but probably these
      new helpers can have more users.
      
      Perhaps they should disable/enable preemption themselves, in this case
      we can remove preempt_disable() in __restore_xstate_sig().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Cc: matt.fleming@intel.com
      Cc: bp@suse.de
      Cc: pbonzini@redhat.com
      Cc: luto@amacapital.net
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Link: http://lkml.kernel.org/r/20150115192028.GD27332@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7575637a
    • O
      x86, fpu: Don't abuse has_fpu in __kernel_fpu_begin/end() · 33a3ebdc
      Oleg Nesterov 提交于
      Now that we have in_kernel_fpu we can remove __thread_clear_has_fpu()
      in __kernel_fpu_begin(). And this allows to replace the asymmetrical
      and nontrivial use_eager_fpu + tsk_used_math check in kernel_fpu_end()
      with the same __thread_has_fpu() check.
      
      The logic becomes really simple; if _begin() does save() then _end()
      needs restore(), this is controlled by __thread_has_fpu(). Otherwise
      they do clts/stts unless use_eager_fpu().
      
      Not only this makes begin/end symmetrical and imo more understandable,
      potentially this allows to change irq_fpu_usable() to avoid all other
      checks except "in_kernel_fpu".
      
      Also, with this patch __kernel_fpu_end() does restore_fpu_checking()
      and WARNs if it fails instead of math_state_restore(). I think this
      looks better because we no longer need __thread_fpu_begin(), and it
      would be better to report the failure in this case.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Cc: matt.fleming@intel.com
      Cc: bp@suse.de
      Cc: pbonzini@redhat.com
      Cc: luto@amacapital.net
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Link: http://lkml.kernel.org/r/20150115192005.GC27332@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      33a3ebdc
    • O
      x86, fpu: Introduce per-cpu in_kernel_fpu state · 14e153ef
      Oleg Nesterov 提交于
      interrupted_kernel_fpu_idle() tries to detect if kernel_fpu_begin()
      is safe or not. In particular it should obviously deny the nested
      kernel_fpu_begin() and this logic looks very confusing.
      
      If use_eager_fpu() == T we rely on a) __thread_has_fpu() check in
      interrupted_kernel_fpu_idle(), and b) on the fact that _begin() does
      __thread_clear_has_fpu().
      
      Otherwise we demand that the interrupted task has no FPU if it is in
      kernel mode, this works because __kernel_fpu_begin() does clts() and
      interrupted_kernel_fpu_idle() checks X86_CR0_TS.
      
      Add the per-cpu "bool in_kernel_fpu" variable, and change this code
      to check/set/clear it. This allows to do more cleanups and fixes, see
      the next changes.
      
      The patch also moves WARN_ON_ONCE() under preempt_disable() just to
      make this_cpu_read() look better, this is not really needed. And in
      fact I think we should move it into __kernel_fpu_begin().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Cc: matt.fleming@intel.com
      Cc: bp@suse.de
      Cc: pbonzini@redhat.com
      Cc: luto@amacapital.net
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Link: http://lkml.kernel.org/r/20150115191943.GB27332@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      14e153ef
  9. 30 5月, 2014 1 次提交
  10. 12 3月, 2014 1 次提交
    • S
      x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU · 731bd6a9
      Suresh Siddha 提交于
      For non-eager fpu mode, thread's fpu state is allocated during the first
      fpu usage (in the context of device not available exception). This
      (math_state_restore()) can be a blocking call and hence we enable
      interrupts (which were originally disabled when the exception happened),
      allocate memory and disable interrupts etc.
      
      But the eager-fpu mode, call's the same math_state_restore() from
      kernel_fpu_end(). The assumption being that tsk_used_math() is always
      set for the eager-fpu mode and thus avoid the code path of enabling
      interrupts, allocating fpu state using blocking call and disable
      interrupts etc.
      
      But the below issue was noticed by Maarten Baert, Nate Eldredge and
      few others:
      
      If a user process dumps core on an ecrypt fs while aesni-intel is loaded,
      we get a BUG() in __find_get_block() complaining that it was called with
      interrupts disabled; then all further accesses to our ecrypt fs hang
      and we have to reboot.
      
      The aesni-intel code (encrypting the core file that we are writing) needs
      the FPU and quite properly wraps its code in kernel_fpu_{begin,end}(),
      the latter of which calls math_state_restore(). So after kernel_fpu_end(),
      interrupts may be disabled, which nobody seems to expect, and they stay
      that way until we eventually get to __find_get_block() which barfs.
      
      For eager fpu, most the time, tsk_used_math() is true. At few instances
      during thread exit, signal return handling etc, tsk_used_math() might
      be false.
      
      In kernel_fpu_end(), for eager-fpu, call math_state_restore()
      only if tsk_used_math() is set. Otherwise, don't bother. Kernel code
      path which cleared tsk_used_math() knows what needs to be done
      with the fpu state.
      Reported-by: NMaarten Baert <maarten-baert@hotmail.com>
      Reported-by: NNate Eldredge <nate@thatsmathematics.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSuresh Siddha <sbsiddha@gmail.com>
      Link: http://lkml.kernel.org/r/1391410583.3801.6.camel@europa
      Cc: George Spelvin <linux@horizon.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      731bd6a9
  11. 13 11月, 2013 1 次提交
  12. 27 7月, 2013 1 次提交
    • H
      x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz · eaa5a990
      H.J. Lu 提交于
      GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:
      
      		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
      		asm volatile("fxsave %0" : : "m" (fx_scratch));
      		mask = fx_scratch.mxcsr_mask;
      		if (mask == 0)
      			mask = 0x0000ffbf;
      
      to
      
      		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
      		asm volatile("fxsave %0" : : "m" (fx_scratch));
      		mask = 0x0000ffbf;
      
      since asm statement doesn’t say it will update fx_scratch.  As the
      result, the DAZ bit will be cleared.  This patch fixes it. This bug
      dates back to at least kernel 2.6.12.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      eaa5a990
  13. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  14. 07 6月, 2013 1 次提交
  15. 31 5月, 2013 1 次提交
    • P
      x86: Allow FPU to be used at interrupt time even with eagerfpu · 5187b28f
      Pekka Riikonen 提交于
      With the addition of eagerfpu the irq_fpu_usable() now returns false
      negatives especially in the case of ksoftirqd and interrupted idle task,
      two common cases for FPU use for example in networking/crypto.  With
      eagerfpu=off FPU use is possible in those contexts.  This is because of
      the eagerfpu check in interrupted_kernel_fpu_idle():
      
      ...
        * For now, with eagerfpu we will return interrupted kernel FPU
        * state as not-idle. TBD: Ideally we can change the return value
        * to something like __thread_has_fpu(current). But we need to
        * be careful of doing __thread_clear_has_fpu() before saving
        * the FPU etc for supporting nested uses etc. For now, take
        * the simple route!
      ...
       	if (use_eager_fpu())
       		return 0;
      
      As eagerfpu is automatically "on" on those CPUs that also have the
      features like AES-NI this patch changes the eagerfpu check to return 1 in
      case the kernel_fpu_begin() has not been said yet.  Once it has been the
      __thread_has_fpu() will start returning 0.
      
      Notice that with eagerfpu the __thread_has_fpu is always true initially.
      FPU use is thus always possible no matter what task is under us, unless
      the state has already been saved with kernel_fpu_begin().
      
      [ hpa: this is a performance regression, not a correctness regression,
        but since it can be quite serious on CPUs which need encryption at
        interrupt time I am marking this for urgent/stable. ]
      Signed-off-by: NPekka Riikonen <priikone@iki.fi>
      Link: http://lkml.kernel.org/r/alpine.GSO.2.00.1305131356320.18@git.silcnet.org
      Cc: <stable@vger.kernel.org> v3.7+
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5187b28f
  16. 15 11月, 2012 1 次提交
  17. 22 9月, 2012 1 次提交
    • S
      x86, kvm: fix kvm's usage of kernel_fpu_begin/end() · b1a74bf8
      Suresh Siddha 提交于
      Preemption is disabled between kernel_fpu_begin/end() and as such
      it is not a good idea to use these routines in kvm_load/put_guest_fpu()
      which can be very far apart.
      
      kvm_load/put_guest_fpu() routines are already called with
      preemption disabled and KVM already uses the preempt notifier to save
      the guest fpu state using kvm_put_guest_fpu().
      
      So introduce __kernel_fpu_begin/end() routines which don't touch
      preemption and use them instead of kernel_fpu_begin/end()
      for KVM's use model of saving/restoring guest FPU state.
      
      Also with this change (and with eagerFPU model), fix the host cr0.TS vm-exit
      state in the case of VMX. For eagerFPU case, host cr0.TS is always clear.
      So no need to worry about it. For the traditional lazyFPU restore case,
      change the cr0.TS bit for the host state during vm-exit to be always clear
      and cr0.TS bit is set in the __vmx_load_host_state() when the FPU
      (guest FPU or the host task's FPU) state is not active. This ensures
      that the host/guest FPU state is properly saved, restored
      during context-switch and with interrupts (using irq_fpu_usable()) not
      stomping on the active FPU state.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1348164109.26695.338.camel@sbsiddha-desk.sc.intel.com
      Cc: Avi Kivity <avi@redhat.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      b1a74bf8
  18. 19 9月, 2012 2 次提交