1. 13 10月, 2008 13 次提交
  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 2 次提交
    • 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
    • J
      kgdb: fix NMI hangs · d3597524
      Jason Wessel 提交于
      This patch fixes the hang regression with kgdb when the NMI interrupt
      comes in while the master core is returning from an exception.
      
      Adjust the NMI logic such that KGDB will not stop NMI exceptions from
      occurring by in general returning NOTIFY_DONE.  It is not possible to
      distinguish the debug NMI sync vs the normal NMI apic interrupt so
      kgdb needs to catch the unknown NMI if it the debugger was previously
      active on one of the cpus.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3597524
  16. 17 4月, 2008 1 次提交