1. 13 10月, 2008 15 次提交
  2. 23 9月, 2008 1 次提交
    • S
      signals: demultiplexing SIGTRAP signal · da654b74
      Srinivasa Ds 提交于
      Currently a SIGTRAP can denote any one of below reasons.
      	- Breakpoint hit
      	- H/W debug register hit
      	- Single step
      	- Signal sent through kill() or rasie()
      
      Architectures like powerpc/parisc provides infrastructure to demultiplex
      SIGTRAP signal by passing down the information for receiving SIGTRAP through
      si_code of siginfot_t structure. Here is an attempt is generalise this
      infrastructure by extending it to x86 and x86_64 archs.
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: akpm@linux-foundation.org
      Cc: paulus@samba.org
      Cc: linuxppc-dev@ozlabs.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      da654b74
  3. 16 8月, 2008 1 次提交
  4. 15 8月, 2008 1 次提交
  5. 01 8月, 2008 1 次提交
  6. 31 7月, 2008 2 次提交
  7. 26 7月, 2008 1 次提交
    • S
      x64, fpu: fix possible FPU leakage in error conditions · 6ffac1e9
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6ffac1e9
  8. 19 7月, 2008 1 次提交
  9. 18 7月, 2008 2 次提交
  10. 15 7月, 2008 1 次提交
  11. 09 7月, 2008 7 次提交
  12. 26 5月, 2008 2 次提交
  13. 25 5月, 2008 1 次提交
  14. 20 4月, 2008 3 次提交
  15. 18 4月, 2008 1 次提交
    • J
      kgdb: fix several kgdb regressions · 737a460f
      Jason Wessel 提交于
      kgdb core fixes:
      - Check to see that mm->mmap_cache is not null before calling
        flush_cache_range(), else on arch=ARM it will cause a fatal
        fault.
      
      - Breakpoints should only be restored if they are in the BP_ACTIVE
        state.
      
      - Fix a typo in comments to "kgdb_register_io_module"
      
      x86 kgdb fixes:
      - Fix the x86 arch handler such that on a kill or detach that the
        appropriate cleanup on the single stepping flags gets run.
      
      - Add in the DIE_NMIWATCHDOG call for x86_64
      
      - Touch the nmi watchdog before returning the system to normal
        operation after performing any kind of kgdb operation, else
        the possibility exists to trigger the watchdog.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      737a460f