1. 30 1月, 2008 14 次提交
  2. 16 1月, 2008 1 次提交
    • P
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra 提交于
      On Sat, 2007-12-29 at 18:06 +0100, Marcin Slusarz wrote:
      > Hi
      > Today I've got this (while i was upgrading my gentoo box):
      >
      > WARNING: at kernel/lockdep.c:2658 check_flags()
      > Pid: 21680, comm: conftest Not tainted 2.6.24-rc6 #63
      >
      > Call Trace:
      >  [<ffffffff80253457>] check_flags+0x1c7/0x1d0
      >  [<ffffffff80257217>] lock_acquire+0x57/0xc0
      >  [<ffffffff8024d5c0>] __atomic_notifier_call_chain+0x60/0xd0
      >  [<ffffffff8024d641>] atomic_notifier_call_chain+0x11/0x20
      >  [<ffffffff8024d67e>] notify_die+0x2e/0x30
      >  [<ffffffff8020da0a>] do_divide_error+0x5a/0xa0
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80255b89>] trace_hardirqs_on+0xd9/0x180
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80523c2d>] error_exit+0x0/0xa9
      >
      > possible reason: unannotated irqs-off.
      > irq event stamp: 4693
      > hardirqs last  enabled at (4693): [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      > hardirqs last disabled at (4692): [<ffffffff80522c17>] trace_hardirqs_off_thunk+0x35/0x37
      > softirqs last  enabled at (3546): [<ffffffff80238343>] __do_softirq+0xb3/0xd0
      > softirqs last disabled at (3521): [<ffffffff8020c97c>] call_softirq+0x1c/0x30
      
      more early fixups for notify_die()..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fb1dac90
  3. 21 12月, 2007 1 次提交
    • I
      x86: fix die() to not be preemptible · c0a698b7
      Ingo Molnar 提交于
      Andrew "Eagle Eye" Morton noticed that we use raw_local_save_flags()
      instead of raw_local_irq_save(flags) in die(). This allows the
      preemption of oopsing contexts - which is highly undesirable. It also
      causes CONFIG_DEBUG_PREEMPT to complain, as reported by Miles Lane.
      
      this bug was introduced via:
      
        commit 39743c9e
        Author: Andi Kleen <ak@suse.de>
        Date:   Fri Oct 19 20:35:03 2007 +0200
      
            x86: use raw locks during oopses
      
      -               spin_lock_irqsave(&die.lock, flags);
      +               __raw_spin_lock(&die.lock);
      +               raw_local_save_flags(flags);
      
      that is not a correct open-coding of spin_lock_irqsave(): both the
      ordering is wrong (irqs should be disabled _first_), and the wrong
      flags-saving API was used.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c0a698b7
  4. 27 11月, 2007 2 次提交
    • P
      lockdep: annotate do_debug() trap handler · 000f4a9e
      Peter Zijlstra 提交于
      Ensure the hardirq state is consistent before using locks. Use the rare
      trace_hardirqs_fixup() because the trap can happen in any context.
      
      resolves this rare lockdep warning:
      
      WARNING: at kernel/lockdep.c:2658 check_flags()
       [<c013571e>] check_flags+0x90/0x140
       [<c0138a69>] lock_release+0x4b/0x1d0
       [<c0507fea>] notifier_call_chain+0x2a/0x47
       [<c050806b>] __atomic_notifier_call_chain+0x64/0x6d
       [<c0508007>] __atomic_notifier_call_chain+0x0/0x6d
       [<c050808b>] atomic_notifier_call_chain+0x17/0x1a
       [<c0131802>] notify_die+0x30/0x34
       [<c0506b09>] do_debug+0x3e/0xd4
       [<c050658f>] debug_stack_correct+0x27/0x2c
       [<c04be389>] tcp_rcv_established+0x1/0x620
       [<c04c38c2>] tcp_v4_do_rcv+0x2b/0x313
       [<c04c56b6>] tcp_v4_rcv+0x467/0x85d
       [<c0505ff2>] _spin_lock_nested+0x27/0x32
       [<c04c5a4d>] tcp_v4_rcv+0x7fe/0x85d
       [<c04c560e>] tcp_v4_rcv+0x3bf/0x85d
       [<c04adbb5>] ip_local_deliver_finish+0x11b/0x1b0
       [<c04adac8>] ip_local_deliver_finish+0x2e/0x1b0
       [<c04ada7b>] ip_rcv_finish+0x27b/0x29a
       [<c04961e5>] netif_receive_skb+0xfb/0x2a6
       [<c04add0f>] ip_rcv+0x0/0x1fb
       [<c0496354>] netif_receive_skb+0x26a/0x2a6
       [<c04961e5>] netif_receive_skb+0xfb/0x2a6
       [<c049872e>] process_backlog+0x7f/0xc6
       [<c04983ba>] net_rx_action+0xb9/0x1ac
       [<c0498348>] net_rx_action+0x47/0x1ac
       [<c01376cb>] trace_hardirqs_on+0x118/0x16b
       [<c01225e2>] __do_softirq+0x49/0xa2
       [<c010595f>] do_softirq+0x60/0xdd
       [<c0506300>] _spin_unlock_irq+0x20/0x2c
       [<c0103e4f>] restore_nocheck+0x12/0x15
       [<c01440e1>] handle_fasteoi_irq+0x0/0x9b
       [<c0105a70>] do_IRQ+0x94/0xaa
       [<c0506300>] _spin_unlock_irq+0x20/0x2c
       [<c0104832>] common_interrupt+0x2e/0x34
       [<c0114703>] native_safe_halt+0x2/0x3
       [<c0102c01>] default_idle+0x44/0x65
       [<c010257f>] cpu_idle+0x42/0x50
       [<c076ea09>] start_kernel+0x26b/0x270
       [<c076e317>] unknown_bootoption+0x0/0x196
       =======================
      irq event stamp: 559190
      hardirqs last  enabled at (559190): [<c0507316>] kprobe_exceptions_notify+0x299/0x305
      hardirqs last disabled at (559189): [<c05067bf>] do_int3+0x1d/0x95
      softirqs last  enabled at (559172): [<c010595f>] do_softirq+0x60/0xdd
      softirqs last disabled at (559181): [<c010595f>] do_softirq+0x60/0xdd
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      000f4a9e
    • A
      x86: printk kernel version in WARN_ON and other dump_stack users · 57c351de
      Arjan van de Ven 提交于
      today, all oopses contain a version number of the kernel, which is nice
      because the people who actually do bother to read the oops get this
      vital bit of information always without having to ask the reporter in
      another round trip.
      
      However, WARN_ON() and many other dump_stack() users right now lack this
      information; the patch below adds this. This information is essential
      for getting people to use their time effectively when looking at these
      things; in addition, it's essential for tools that try to collect
      statistics about defects.
      
      Please consider, since its so simple and important for long term kernel
      quality processes.
      
      The code is identical between 32/64 bit; a lot of this code should be
      unified over time, the patch keeps the identical-ness intact.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      57c351de
  5. 25 10月, 2007 1 次提交
  6. 20 10月, 2007 4 次提交
  7. 18 10月, 2007 3 次提交
  8. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      Dave Jones 提交于
      Since the x86 merge, lots of files that referenced their own filenames
      are no longer correct.  Rather than keep them up to date, just delete
      them, as they add no real value.
      
      Additionally:
      - fix up comment formatting in scx200_32.c
      - Remove a credit from myself in setup_64.c from a time when we had no SCM
      - remove longwinded history from tsc_32.c which can be figured out from
        git.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  9. 11 10月, 2007 2 次提交
  10. 01 9月, 2007 1 次提交
    • L
      x86: be even more careful about checking the stack frame on dumping · 36ad4885
      Linus Torvalds 提交于
      lguest didn't initialize the kernel stack the way a real i386 kernel
      does, and ended up triggering a corner-case in the stack frame checking
      that doesn't happen on naive i386, and that the stack dumping didn't
      handle quite right.
      
      This makes the frame handling more correct, and tries to clarify the
      code at the same time so that it's a bit more obvious what is going on.
      
      Thanks to Rusty Russell for debugging the lguest failure-
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36ad4885
  11. 23 7月, 2007 2 次提交
    • A
      x86: Stop MCEs and NMIs during code patching · 8f4e956b
      Andi Kleen 提交于
      When a machine check or NMI occurs while multiple byte code is patched
      the CPU could theoretically see an inconsistent instruction and crash.
      Prevent this by temporarily disabling MCEs and returning early in the
      NMI handler.
      
      Based on discussion with Mathieu Desnoyers.
      
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f4e956b
    • 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
  12. 22 7月, 2007 2 次提交
  13. 20 7月, 2007 2 次提交
  14. 19 7月, 2007 1 次提交
  15. 18 7月, 2007 1 次提交
  16. 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
  17. 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