An error occurred fetching the project authors.
  1. 30 Jul, 2008 5 commits
  2. 26 Jul, 2008 1 commit
    • Suresh Siddha's avatar
      x64, fpu: fix possible FPU leakage in error conditions · 6ffac1e9
      Suresh Siddha authored
      On Thu, Jul 24, 2008 at 03:43:44PM -0700, Linus Torvalds wrote:
      > So how about this patch as a starting point? This is the RightThing(tm) to
      > do regardless, and if it then makes it easier to do some other cleanups,
      > we should do it first. What do you think?
      
      restore_fpu_checking() calls init_fpu() in error conditions.
      
      While this is wrong(as our main intention is to clear the fpu state of
      the thread), this was benign before commit 92d140e2 ("x86: fix taking
      DNA during 64bit sigreturn").
      
      Post commit 92d140e2, live FPU registers may not belong to this
      process at this error scenario.
      
      In the error condition for restore_fpu_checking() (especially during the
      64bit signal return), we are doing init_fpu(), which saves the live FPU
      register state (possibly belonging to some other process context) into
      the thread struct (through unlazy_fpu() in init_fpu()). This is wrong
      and can leak the FPU data.
      
      For the signal handler restore error condition in restore_i387(), clear
      the fpu state present in the thread struct(before ultimately sending a
      SIGSEGV for badframe).
      
      For the paranoid error condition check in math_state_restore(), send a
      SIGSEGV, if we fail to restore the state.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6ffac1e9
  3. 24 Jul, 2008 1 commit
    • Linus Torvalds's avatar
      x86-64: Clean up 'save/restore_i387()' usage · b30f3ae5
      Linus Torvalds authored
      Suresh Siddha wants to fix a possible FPU leakage in error conditions,
      but the fact that save/restore_i387() are inlines in a header file makes
      that harder to do than necessary.  So start off with an obvious cleanup.
      
      This just moves the x86-64 version of save/restore_i387() out of the
      header file, and moves it to the only file that it is actually used in:
      arch/x86/kernel/signal_64.c.  So exposing it in a header file was wrong
      to begin with.
      
      [ Side note: I'd like to fix up some of the games we play with the
        32-bit version of these functions too, but that's a separate
        matter.  The 32-bit versions are shared - under different names
        at that! - by both the native x86-32 code and the x86-64 32-bit
        compatibility code ]
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b30f3ae5
  4. 22 Jul, 2008 1 commit
    • Vegard Nossum's avatar
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum authored
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  5. 04 Jun, 2008 1 commit
  6. 10 May, 2008 1 commit
  7. 19 Apr, 2008 3 commits
  8. 17 Apr, 2008 1 commit
  9. 19 Feb, 2008 1 commit
  10. 04 Feb, 2008 1 commit
  11. 30 Jan, 2008 3 commits
  12. 11 Oct, 2007 1 commit