1. 31 Jul, 2006 14 commits
  2. 30 Jul, 2006 2 commits
    • Linus Torvalds's avatar
      Linux v2.6.18-rc3 · b6ff5083
      Linus Torvalds authored
      b6ff5083
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · af652c26
      Linus Torvalds authored
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        [ARM] 3734/1: Fix the unused variable warning in __iounmap()
        [ARM] 3737/1: Export ARM copy/clear_user_page symbols
        [ARM] 3736/1: xscale: don't mis-report 80219 as an iop32x
        [ARM] 3733/2: S3C24XX: Remove old IDE registers in Anubis
        [ARM] 3732/1: S3C24XX: tidy syntax in osiris and anubis machines
        [ARM] Fix SMP booting
        [ARM] 3731/1: Allow IRQ definitions of IQ80331 and IQ80332 to co-exist
        [ARM] 3730/1: ep93xx: enable usb ohci driver in the defconfig
        [ARM] Fix cats build
      af652c26
  3. 29 Jul, 2006 19 commits
  4. 28 Jul, 2006 5 commits
    • Andi Kleen's avatar
      [PATCH] i386: Do backtrace fallback too · c97d20a6
      Andi Kleen authored
      
      Similar patch to earlier x86-64 patch. When the dwarf2 unwinder fails
      dump the left over stack with the old unwinder.
      
      Also some clarifications in the headers.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c97d20a6
    • Andi Kleen's avatar
      b783fd92
    • Andi Kleen's avatar
      [PATCH] x86_64: Dump leftover backtrace entries when dwarf2 unwinder got stuck · b13761ec
      Andi Kleen authored
      
      The dwarf2 unwinder currently often gets stuck because a lot
      of assembly code doesn't have proper dwarf2 annotiation yet.
      
      This currently often happens with __down. Should fix this by
      adding proper dwarf2 annotation to all inline assembly. However
      until that's done we need a quick fix for 2.6.18 to avoid
      incomplete backtraces.
      
      So when this happens dump the rest of the stack with the old unwinder
      instead of silently not dumping it. There was already a optional
      "both" mode that dumped both, but that was too ugly.
      
      I also clarified the headers for the different backtraces a bit.
      
      Also add a clear error message for missing dwarf2
      annotation that people can work on.
      
      And I removed a dead variable left over from Ingo's changes.
      
      Cc: mingo@elte.hu
      Cc: jbeulich@novell.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b13761ec
    • bibo mao's avatar
      [PATCH] x86_64: Enlarge debug stack for nested kprobes · a4045dff
      bibo mao authored
      
      In x86_64 platform, INT1 and INT3 trap stack is IST stack called DEBUG_STACK,
      when INT1/INT3 trap happens, system will switch to DEBUG_STACK by hardware.
      Current DEBUG_STACK size is 4K, when int1/int3 trap happens, kernel will
      minus current DEBUG_STACK IST value by 4k. But if int3/int1 trap is nested,
      it will destroy other vector's IST stack. This patch modifies this, it sets
      DEBUG_STACK size as 8K and allows two level of nested int1/int3 trap.
      
      Kprobe DEBUG_STACK may be nested, because kprobe handler may be probed
      by other kprobes.
      
      Thanks jbeulich for pointing out error in the first patch.
      
      [AK: nested kprobes are pretty dubious. Hopefully one nest
      will be enough. This will cost 8K per CPU (4K more than before)]
      Signed-off-by: default avatarbibo, mao <bibo.mao@intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a4045dff
    • Andi Kleen's avatar
      [PATCH] x86_64: Don't clobber r8-r11 in int 0x80 handler · 0e92da4a
      Andi Kleen authored
      
      When int 0x80 is called from long mode r8-r11 would leak out of the
      kernel (or rather they would be filled with some values from
      the kernel stack). I don't think it's a security issue because
      the values come from the fixed stack frame which should be near
      always user registers from a previous interrupt.
      
      Still better fix it.
      
      Longer term the register save macros need to be cleaned up
      to avoid such mistakes in the future.
      
      Original analysis from Richard Brunner, fix by me.
      
      Cc: Richard.Brunner@amd.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0e92da4a