1. 11 10月, 2007 2 次提交
  2. 23 7月, 2007 1 次提交
    • M
      x86: i386-show-unhandled-signals-v3 · abd4f750
      Masoud Asgharifard Sharbiani 提交于
      This patch makes the i386 behave the same way that x86_64 does when a
      segfault happens.  A line gets printed to the kernel log so that tools
      that need to check for failures can behave more uniformly between
      debug.show_unhandled_signals sysctl variable to 0 (or by doing echo 0 >
      /proc/sys/debug/exception-trace)
      
      Also, all of the lines being printed are now using printk_ratelimit() to
      deny the ability of DoS from a local user with a program like the
      following:
      
      main()
      {
             while (1)
                     if (!fork()) *(int *)0 = 0;
      }
      
      This new revision also includes the fix that Andrew did which got rid of
      new sysctl that was added to the system in earlier versions of this.
      Also, 'show-unhandled-signals' sysctl has been renamed back to the old
      'exception-trace' to avoid breakage of people's scripts.
      
      AK: Enabling by default for i386 will be likely controversal, but let's see what happens
      AK: Really folks, before complaining just fix your segfaults
      AK: I bet this will find a lot of silent issues
      Signed-off-by: NMasoud Sharbiani <masouds@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      [ Personally, I've found the complaints useful on x86-64, so I'm all for
        this. That said, I wonder if we could do it more prettily..   -Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      abd4f750
  3. 20 7月, 2007 1 次提交
  4. 18 7月, 2007 2 次提交
  5. 17 7月, 2007 1 次提交
    • H
      generic bug: use show_regs() instead of dump_stack() · 608e2619
      Heiko Carstens 提交于
      The current generic bug implementation has a call to dump_stack() in case a
      WARN_ON(whatever) gets hit.  Since report_bug(), which calls dump_stack(),
      gets called from an exception handler we can do better: just pass the
      pt_regs structure to report_bug() and pass it to show_regs() in case of a
      warning.  This will give more debug informations like register contents,
      etc...  In addition this avoids some pointless lines that dump_stack()
      emits, since it includes a stack backtrace of the exception handler which
      is of no interest in case of a warning.  E.g.  on s390 the following lines
      are currently always present in a stack backtrace if dump_stack() gets
      called from report_bug():
      
       [<000000000001517a>] show_trace+0x92/0xe8)
       [<0000000000015270>] show_stack+0xa0/0xd0
       [<00000000000152ce>] dump_stack+0x2e/0x3c
       [<0000000000195450>] report_bug+0x98/0xf8
       [<0000000000016cc8>] illegal_op+0x1fc/0x21c
       [<00000000000227d6>] sysc_return+0x0/0x10
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      608e2619
  6. 09 6月, 2007 1 次提交
    • A
      x86_64: oops_begin() fix · b39b7036
      Andrew Morton 提交于
      We don't want to see this:
      
      >  BUG: using smp_processor_id() in preemptible [00000001] code: bash/3857
      >  caller is oops_begin+0xb/0x6f
      >
      >  Call Trace:
      >  [<ffffffff8020ab4d>] show_trace+0x34/0x4f
      >  [<ffffffff8020ab7a>] dump_stack+0x12/0x17
      >  [<ffffffff8030d92d>] debug_smp_processor_id+0xad/0xbc
      >  [<ffffffff8042388f>] oops_begin+0xb/0x6f
      >  [<ffffffff8042520b>] do_page_fault+0x66a/0x7c0
      >  [<ffffffff804234bd>] error_exit+0x0/0x84
      >
      
      coming out when the kernel is trying to oops.
      
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b39b7036
  7. 15 5月, 2007 1 次提交
    • L
      Revert "ipmi: add new IPMI nmi watchdog handling" · faa8b6c3
      Linus Torvalds 提交于
      This reverts commit f64da958.
      
      Andi Kleen is unhappy with the changes, and they really do not seem
      worth it.  IPMI could use DIE_NMI_IPI instead of the new callback, even
      though that ends up having its own set of problems too, mainly because
      the IPMI code cannot really know the NMI was from IPMI or not.
      
      Manually fix up conflicts in arch/x86_64/kernel/traps.c and
      drivers/char/ipmi/ipmi_watchdog.c.
      
      Cc: Andi Kleen <ak@suse.de>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faa8b6c3
  8. 11 5月, 2007 1 次提交
  9. 09 5月, 2007 2 次提交
  10. 03 5月, 2007 2 次提交
  11. 04 1月, 2007 1 次提交
  12. 16 12月, 2006 1 次提交
    • L
      Remove stack unwinder for now · d1526e2c
      Linus Torvalds 提交于
      It has caused more problems than it ever really solved, and is
      apparently not getting cleaned up and fixed.  We can put it back when
      it's stable and isn't likely to make warning or bug events worse.
      
      In the meantime, enable frame pointers for more readable stack traces.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1526e2c
  13. 09 12月, 2006 1 次提交
    • J
      [PATCH] Generic BUG for x86-64 · c31a0bf3
      Jeremy Fitzhardinge 提交于
      This makes x86-64 use the generic BUG machinery.
      
      The main advantage in using the generic BUG machinery for x86-64 is that
      the inlined overhead of BUG is just the ud2a instruction; the file+line
      information are no longer inlined into the instruction stream.  This
      reduces cache pollution.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c31a0bf3
  14. 07 12月, 2006 9 次提交
  15. 29 11月, 2006 1 次提交
  16. 18 11月, 2006 1 次提交
    • I
      [PATCH] x86_64: stack unwinder crash fix · 0796bdb7
      Ingo Molnar 提交于
      the new dwarf2 unwinder crashes while trying to dump the stack:
      
        Leftover inexact backtrace:
      
        Unable to handle kernel paging request at ffffffff82800000 RIP:
         [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        PGD 203027 PUD 205027 PMD 0
        Oops: 0000 [2] PREEMPT SMP
        CPU 0
        Modules linked in:
        Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
        RIP: 0010:[<ffffffff8026cf26>]  [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        RSP: 0000:ffff81003fb9d848  EFLAGS: 00010006
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffffffff805b3520 RDI: 0000000000000000
        RBP: ffffffff827ffff9 R08: ffffffff80aad000 R09: 0000000000000005
        R10: ffffffff80aae000 R11: ffffffff8037961b R12: ffff81003fb9d858
        R13: 0000000000000000 R14: ffffffff80598460 R15: ffffffff80ab1fc0
        FS:  0000000000000000(0000) GS:ffffffff806c4200(0000) knlGS:0000000000000000
        CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        CR2: ffffffff82800000 CR3: 0000000000201000 CR4: 00000000000006e0
      
      this crash happened because it did not sanitize the dwarf2 data it
      got, and got an unaligned stack pointer - which happily walked past
      the process stack (and eventually reached the end of kernel memory
      and pagefaulted there) due to this naive iteration condition:
      
              HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);
      
      note that i386 is alot more conservative when it comes to trusting
      stack pointers:
      
        static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
        {
               return  p > (void *)tinfo &&
                       p < (void *)tinfo + THREAD_SIZE - 3;
        }
      
      but the x86_64 code did not take this bit of i386 code.
      
      The fix is to align the stack pointer.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0796bdb7
  17. 06 10月, 2006 1 次提交
  18. 26 9月, 2006 11 次提交
    • A
      [PATCH] Don't use kernel_text_address in oops context · e8c7391d
      Andi Kleen 提交于
      Because it can take spinlocks.
      
      Suggested by Mathieu Desnoyers
      
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      e8c7391d
    • K
      [PATCH] Remove most of the special cases for the debug IST stack · f5741644
      Keith Owens 提交于
      Remove most of the special cases for the debug IST stack.  This is a
      follow on clean up patch, it requires the bug fix patch that adds
      orig_ist.
      Signed-off-by: NKeith Owens <kaos@ocs.com.au>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      f5741644
    • A
      [PATCH] Remove safe_smp_processor_id() · 151f8cc1
      Andi Kleen 提交于
      And replace all users with ordinary smp_processor_id.  The function
      was originally added to get some basic oops information out even
      if the GS register was corrupted. However that didn't
      work for some anymore because printk is needed to print the oops
      and it uses smp_processor_id() already. Also GS register corruptions
      are not particularly common anymore.
      
      This also helps the Xen port which would otherwise need to
      do this in a special way because it can't access the local APIC.
      
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      151f8cc1
    • A
      [PATCH] wire up oops_enter()/oops_exit() · abf0f109
      Andrew Morton 提交于
      Implement pause_on_oops() on x86_64.
      
      AK: I redid the patch to do the oops_enter/exit in the existing
      oops_begin()/end(). This makes it much shorter.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      abf0f109
    • A
      [PATCH] non lazy "sleazy" fpu implementation · e07e23e1
      Arjan van de Ven 提交于
      Right now the kernel on x86-64 has a 100% lazy fpu behavior: after *every*
      context switch a trap is taken for the first FPU use to restore the FPU
      context lazily.  This is of course great for applications that have very
      sporadic or no FPU use (since then you avoid doing the expensive
      save/restore all the time).  However for very frequent FPU users...  you
      take an extra trap every context switch.
      
      The patch below adds a simple heuristic to this code: After 5 consecutive
      context switches of FPU use, the lazy behavior is disabled and the context
      gets restored every context switch.  If the app indeed uses the FPU, the
      trap is avoided.  (the chance of the 6th time slice using FPU after the
      previous 5 having done so are quite high obviously).
      
      After 256 switches, this is reset and lazy behavior is returned (until
      there are 5 consecutive ones again).  The reason for this is to give apps
      that do longer bursts of FPU use still the lazy behavior back after some
      time.
      
      [akpm@osdl.org: place new task_struct field next to jit_keyring to save space]
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      e07e23e1
    • A
      [PATCH] Check for end of stack trace before falling back · be7a9170
      Andi Kleen 提交于
      Signed-off-by: NAndi Kleen <ak@suse.de>
      be7a9170
    • A
      [PATCH] Merge stacktrace and show_trace · c0b766f1
      Andi Kleen 提交于
      This unifies the standard backtracer and the new stacktrace
      in memory backtracer. The standard one is converted to use callbacks
      and then reimplement stacktrace using new callbacks.
      
      The main advantage is that stacktrace can now use the new dwarf2 unwinder
      and avoid false positives in many cases.
      
      I kept it simple to make sure the standard backtracer stays reliable.
      
      Cc: mingo@elte.hu
      Signed-off-by: NAndi Kleen <ak@suse.de>
      c0b766f1
    • A
      [PATCH] Convert x86-64 to early param · 2c8c0e6b
      Andi Kleen 提交于
      Instead of hackish manual parsing
      
      Requires earlier i386 patchkit, but also fixes i386 early_printk again.
      
      I removed some obsolete really early parameters which didn't do anything useful.
      Also made a few parameters that needed it early (mostly oops printing setup)
      
      Also removed one panic check that wasn't visible without
      early console anyways (the early console is now initialized after that
      panic)
      
      This cleans up a lot of code.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      2c8c0e6b
    • A
      [PATCH] Remove all ifdefs for local/io apic · 7f11d8a5
      Andi Kleen 提交于
      IO-APIC or local APIC can only be disabled at runtime anyways and
      Kconfig has forced these options on for a long time now.
      
      The Kconfigs are kept only now for the benefit of the shared acpi
      boot.c code.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      7f11d8a5
    • A
      [PATCH] Fix up panic messages for different NMI panics · fac58550
      Andi Kleen 提交于
      When a unknown NMI happened the panic would claim a NMI watchdog timeout.
      Also it would check the variable set by nmi_watchdog=panic and panic then.
      
      Fix up the panic message to be generic
      Unconditionally panic on unknown NMI when panic on unknown nmi is enabled.
      
      Noticed by Jan Beulich
      
      Cc: jbeulich@novell.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      fac58550
    • D
      [PATCH] x86: x86 clean up nmi panic messages · c41c5cd3
      Don Zickus 提交于
      Clean up some of the output messages on the nmi error paths to make more
      sense when they are displayed.  This is mainly a cosmetic fix and
      shouldn't impact any normal code path.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      c41c5cd3