1. 13 10月, 2008 9 次提交
  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 次提交
  17. 15 2月, 2008 1 次提交
    • I
      x86: fix "BUG: sleeping function called from invalid context" in print_vma_addr() · e8bff74a
      Ingo Molnar 提交于
      Jiri Kosina reported the following deadlock scenario with
      show_unhandled_signals enabled:
      
       [   68.379022] gnome-settings-[2941] trap int3 ip:3d2c840f34
       sp:7fff36f5d100 error:0<3>BUG: sleeping function called from invalid
       context at kernel/rwsem.c:21
       [   68.379039] in_atomic():1, irqs_disabled():0
       [   68.379044] no locks held by gnome-settings-/2941.
       [   68.379050] Pid: 2941, comm: gnome-settings- Not tainted 2.6.25-rc1 #30
       [   68.379054]
       [   68.379056] Call Trace:
       [   68.379061]  <#DB>  [<ffffffff81064883>] ? __debug_show_held_locks+0x13/0x30
       [   68.379109]  [<ffffffff81036765>] __might_sleep+0xe5/0x110
       [   68.379123]  [<ffffffff812f2240>] down_read+0x20/0x70
       [   68.379137]  [<ffffffff8109cdca>] print_vma_addr+0x3a/0x110
       [   68.379152]  [<ffffffff8100f435>] do_trap+0xf5/0x170
       [   68.379168]  [<ffffffff8100f52b>] do_int3+0x7b/0xe0
       [   68.379180]  [<ffffffff812f4a6f>] int3+0x9f/0xd0
       [   68.379203]  <<EOE>>
       [   68.379229]  in libglib-2.0.so.0.1505.0[3d2c800000+dc000]
      
      and tracked it down to:
      
        commit 03252919
        Author: Andi Kleen <ak@suse.de>
        Date:   Wed Jan 30 13:33:18 2008 +0100
      
            x86: print which shared library/executable faulted in segfault etc. messages
      
      the problem is that we call down_read() from an atomic context.
      
      Solve this by returning from print_vma_addr() if the preempt count is
      elevated. Update preempt_conditional_sti / preempt_conditional_cli to
      unconditionally lift the preempt count even on !CONFIG_PREEMPT.
      Reported-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e8bff74a
  18. 30 1月, 2008 3 次提交