1. 21 Apr, 2009 1 commit
  2. 20 Apr, 2009 3 commits
    • Suresh Siddha's avatar
      x86-64: fix FPU corruption with signals and preemption · 06c38d5e
      Suresh Siddha authored
      In 64bit signal delivery path, clear_used_math() was happening before saving
      the current active FPU state on to the user stack for signal handling. Between
      clear_used_math() and the state store on to the user stack, potentially we
      can get a page fault for the user address and can block. Infact, while testing
      we were hitting the might_fault() in __clear_user() which can do a schedule().
      
      At a later point in time, we will schedule back into this process and
      resume the save state (using "xsave/fxsave" instruction) which can lead
      to DNA fault. And as used_math was cleared before, we will reinit the FP state
      in the DNA fault and continue. This reinit will result in loosing the
      FPU state of the process.
      
      Move clear_used_math() to a point after the FPU state has been stored
      onto the user stack.
      
      This issue is present from a long time (even before the xsave changes
      and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x
      series because of the __clear_user() in this path, which has an explicit
      __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY.
      
      [ Impact: fix FPU state corruption ]
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>			[2.6.28.x, 2.6.29.x]
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      06c38d5e
    • Jack Steiner's avatar
      x86/uv: fix for no memory at paddr 0 · fc61e663
      Jack Steiner authored
      Fix endcase where the memory at physical address 0 does not really
      exist AND one of the sockets on blade 0 has no active cpus.
      
      The memory that _appears_ to be at physical address 0 is actually
      memory that located at a different address but has been remapped by
      the chipset so that it appears to be at physical address 0.
      
      When determining the UV pnode, the algorithm for determining the pnode
      incorrectly used the relocated physical address instead of the actual
      (global) address.
      
      [ Impact: boot failure on partitioned systems ]
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090420132530.GA23156@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fc61e663
    • Ingo Molnar's avatar
      Merge branch 'linus' into x86/urgent · 62d17029
      Ingo Molnar authored
      Merge reason: We need the x86/uv updates from upstream, to queue up
                    dependent fix.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      62d17029
  3. 19 Apr, 2009 19 commits
  4. 18 Apr, 2009 11 commits
  5. 17 Apr, 2009 6 commits