1. 04 12月, 2008 1 次提交
  2. 03 12月, 2008 1 次提交
  3. 25 11月, 2008 1 次提交
    • I
      lockdep: fix unused function warning in kernel/lockdep.c · 7807fafa
      Ingo Molnar 提交于
      Impact: fix build warning
      
      this warning:
      
        kernel/lockdep.c:584: warning: ‘print_lock_dependencies’ defined but not used
      
      triggers because print_lock_dependencies() is only used if both
      CONFIG_TRACE_IRQFLAGS and CONFIG_PROVE_LOCKING are enabled.
      
      But adding #ifdefs is not an option here - it would spread out to 4-5
      other helper functions and uglify the file. So mark this function
      as __used - it's static and the compiler can eliminate it just fine.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7807fafa
  4. 21 11月, 2008 1 次提交
  5. 28 10月, 2008 2 次提交
  6. 20 10月, 2008 1 次提交
  7. 27 8月, 2008 1 次提交
    • Z
      lockdep: fix invalid list_del_rcu in zap_class · 74870172
      Zhu Yi 提交于
      The problem is found during iwlagn driver testing on
      v2.6.27-rc4-176-gb8e6c91c kernel, but it turns out to be a lockdep bug.
      In our testing, we frequently load and unload the iwlagn driver
      (>50 times). Then the MAX_STACK_TRACE_ENTRIES is reached (expected
      behaviour?). The error message with the call trace is as below.
      
      BUG: MAX_STACK_TRACE_ENTRIES too low!
      turning off the locking correctness validator.
      Pid: 4895, comm: iwlagn Not tainted 2.6.27-rc4 #13
      
      Call Trace:
       [<ffffffff81014aa1>] save_stack_trace+0x22/0x3e
       [<ffffffff8105390a>] save_trace+0x8b/0x91
       [<ffffffff81054e60>] mark_lock+0x1b0/0x8fa
       [<ffffffff81056f71>] __lock_acquire+0x5b9/0x716
       [<ffffffffa00d818a>] ieee80211_sta_work+0x0/0x6ea [mac80211]
       [<ffffffff81057120>] lock_acquire+0x52/0x6b
       [<ffffffff81045f0e>] run_workqueue+0x97/0x1ed
       [<ffffffff81045f5e>] run_workqueue+0xe7/0x1ed
       [<ffffffff81045f0e>] run_workqueue+0x97/0x1ed
       [<ffffffff81046ae4>] worker_thread+0xd8/0xe3
       [<ffffffff81049503>] autoremove_wake_function+0x0/0x2e
       [<ffffffff81046a0c>] worker_thread+0x0/0xe3
       [<ffffffff810493ec>] kthread+0x47/0x73
       [<ffffffff8128e3ab>] trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8100cea9>] child_rip+0xa/0x11
       [<ffffffff8100c4df>] restore_args+0x0/0x30
       [<ffffffff810316e1>] finish_task_switch+0x0/0xcc
       [<ffffffff810493a5>] kthread+0x0/0x73
       [<ffffffff8100ce9f>] child_rip+0x0/0x11
      
      Although the above is harmless, when the ilwagn module is removed
      later lockdep will trigger a kernel oops as below.
      
      BUG: unable to handle kernel NULL pointer dereference at
      0000000000000008
      IP: [<ffffffff810531e1>] zap_class+0x24/0x82
      PGD 73128067 PUD 7448c067 PMD 0
      Oops: 0002 [1] SMP
      CPU 0
      Modules linked in: rfcomm l2cap bluetooth autofs4 sunrpc
      nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_ipv6header
      ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand
      acpi_cpufreq dm_mirror dm_log dm_multipath dm_mod snd_hda_intel sr_mod
      snd_seq_dummy snd_seq_oss snd_seq_midi_event battery snd_seq
      snd_seq_device cdrom button snd_pcm_oss snd_mixer_oss snd_pcm
      snd_timer snd_page_alloc e1000e snd_hwdep sg iTCO_wdt
      iTCO_vendor_support ac pcspkr i2c_i801 i2c_core snd soundcore video
      output ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache
      uhci_hcd ohci_hcd ehci_hcd [last unloaded: mac80211]
      Pid: 4941, comm: modprobe Not tainted 2.6.27-rc4 #10
      RIP: 0010:[<ffffffff810531e1>]  [<ffffffff810531e1>]
      zap_class+0x24/0x82
      RSP: 0000:ffff88007bcb3eb0  EFLAGS: 00010046
      RAX: 0000000000068ee8 RBX: ffffffff8192a0a0 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000001dfb RDI: ffffffff816e70b0
      RBP: ffffffffa00cd000 R08: ffffffff816818f8 R09: ffff88007c923558
      R10: ffffe20002ad2408 R11: ffffffff811028ec R12: ffffffff8192a0a0
      R13: 000000000002bd90 R14: 0000000000000000 R15: 0000000000000296
      FS:  00007f9d1cee56f0(0000) GS:ffffffff814a58c0(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000008 CR3: 0000000073047000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process modprobe (pid: 4941, threadinfo ffff88007bcb2000, task
      ffff8800758d1fc0)
      Stack:  ffffffff81057376 0000000000000000 ffffffffa00f7b00
      0000000000000000
       0000000000000080 0000000000618278 00007fff24f16720 0000000000000000
       ffffffff8105d37a ffffffffa00f7b00 ffffffff8105d591 313132303863616d
      Call Trace:
       [<ffffffff81057376>] ? lockdep_free_key_range+0x61/0xf5
       [<ffffffff8105d37a>] ? free_module+0xd4/0xe4
       [<ffffffff8105d591>] ? sys_delete_module+0x1de/0x1f9
       [<ffffffff8106dbfa>] ? audit_syscall_entry+0x12d/0x160
       [<ffffffff8100be2b>] ? system_call_fastpath+0x16/0x1b
      
      Code: b2 00 01 00 00 00 c3 31 f6 49 c7 c0 10 8a 61 81 eb 32 49 39 38
      75 26 48 98 48 6b c0 38 48 8b 90 08 8a 61 81 48 8b 88 00 8a 61 81 <48>
      89 51 08 48 89 0a 48 c7 80 08 8a 61 81 00 02 20 00 48 ff c6
      RIP  [<ffffffff810531e1>] zap_class+0x24/0x82
       RSP <ffff88007bcb3eb0>
      CR2: 0000000000000008
      ---[ end trace a1297e0c4abb0f2e ]---
      
      The root cause for this oops is in add_lock_to_list() when
      save_trace() fails due to MAX_STACK_TRACE_ENTRIES is reached,
      entry->class is assigned but entry is never added into any lock list.
      This makes the list_del_rcu() in zap_class() oops later when the
      module is unloaded. This patch fixes the problem by assigning
      entry->class after save_trace() returns success.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      74870172
  8. 26 8月, 2008 1 次提交
  9. 18 8月, 2008 1 次提交
  10. 14 8月, 2008 1 次提交
  11. 12 8月, 2008 1 次提交
  12. 11 8月, 2008 4 次提交
    • R
      lockdep: handle chains involving classes defined in modules · 8bfe0298
      Rabin Vincent 提交于
      Solve this by marking the classes as unused and not printing information
      about the unused classes.
      Reported-by: NEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: NRabin Vincent <rabin@rab.in>
      Acked-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8bfe0298
    • P
      lockdep: lock protection locks · 7531e2f3
      Peter Zijlstra 提交于
      On Fri, 2008-08-01 at 16:26 -0700, Linus Torvalds wrote:
      
      > On Fri, 1 Aug 2008, David Miller wrote:
      > >
      > > Taking more than a few locks of the same class at once is bad
      > > news and it's better to find an alternative method.
      >
      > It's not always wrong.
      >
      > If you can guarantee that anybody that takes more than one lock of a
      > particular class will always take a single top-level lock _first_, then
      > that's all good. You can obviously screw up and take the same lock _twice_
      > (which will deadlock), but at least you cannot get into ABBA situations.
      >
      > So maybe the right thing to do is to just teach lockdep about "lock
      > protection locks". That would have solved the multi-queue issues for
      > networking too - all the actual network drivers would still have taken
      > just their single queue lock, but the one case that needs to take all of
      > them would have taken a separate top-level lock first.
      >
      > Never mind that the multi-queue locks were always taken in the same order:
      > it's never wrong to just have some top-level serialization, and anybody
      > who needs to take <n> locks might as well do <n+1>, because they sure as
      > hell aren't going to be on _any_ fastpaths.
      >
      > So the simplest solution really sounds like just teaching lockdep about
      > that one special case. It's not "nesting" exactly, although it's obviously
      > related to it.
      
      Do as Linus suggested. The lock protection lock is called nest_lock.
      
      Note that we still have the MAX_LOCK_DEPTH (48) limit to consider, so anything
      that spills that it still up shit creek.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7531e2f3
    • D
      lockdep: shrink held_lock structure · f82b217e
      Dave Jones 提交于
      struct held_lock {
              u64                        prev_chain_key;       /*     0     8 */
              struct lock_class *        class;                /*     8     8 */
              long unsigned int          acquire_ip;           /*    16     8 */
              struct lockdep_map *       instance;             /*    24     8 */
              int                        irq_context;          /*    32     4 */
              int                        trylock;              /*    36     4 */
              int                        read;                 /*    40     4 */
              int                        check;                /*    44     4 */
              int                        hardirqs_off;         /*    48     4 */
      
              /* size: 56, cachelines: 1 */
              /* padding: 4 */
              /* last cacheline: 56 bytes */
      };
      
      struct held_lock {
              u64                        prev_chain_key;       /*     0     8 */
              long unsigned int          acquire_ip;           /*     8     8 */
              struct lockdep_map *       instance;             /*    16     8 */
              unsigned int               class_idx:11;         /*    24:21  4 */
              unsigned int               irq_context:2;        /*    24:19  4 */
              unsigned int               trylock:1;            /*    24:18  4 */
              unsigned int               read:2;               /*    24:16  4 */
              unsigned int               check:2;              /*    24:14  4 */
              unsigned int               hardirqs_off:1;       /*    24:13  4 */
      
              /* size: 32, cachelines: 1 */
              /* padding: 4 */
              /* bit_padding: 13 bits */
              /* last cacheline: 32 bytes */
      };
      
      [mingo@elte.hu: shrunk hlock->class too]
      [peterz@infradead.org: fixup bit sizes]
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      f82b217e
    • P
      lockdep: lock_set_subclass - reset a held lock's subclass · 64aa348e
      Peter Zijlstra 提交于
      this can be used to reset a held lock's subclass, for arbitrary-depth
      iterated data structures such as trees or lists which have per-node
      locks.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      64aa348e
  13. 01 8月, 2008 1 次提交
    • D
      lockdep: fix combinatorial explosion in lock subgraph traversal · 419ca3f1
      David Miller 提交于
      When we traverse the graph, either forwards or backwards, we
      are interested in whether a certain property exists somewhere
      in a node reachable in the graph.
      
      Therefore it is never necessary to traverse through a node more
      than once to get a correct answer to the given query.
      
      Take advantage of this property using a global ID counter so that we
      need not clear all the markers in all the lock_class entries before
      doing a traversal.  A new ID is choosen when we start to traverse, and
      we continue through a lock_class only if it's ID hasn't been marked
      with the new value yet.
      
      This short-circuiting is essential especially for high CPU count
      systems.  The scheduler has a runqueue per cpu, and needs to take
      two runqueue locks at a time, which leads to long chains of
      backwards and forwards subgraphs from these runqueue lock nodes.
      Without the short-circuit implemented here, a graph traversal on
      a runqueue lock can take up to (1 << (N - 1)) checks on a system
      with N cpus.
      
      For anything more than 16 cpus or so, lockdep will eventually bring
      the machine to a complete standstill.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      419ca3f1
  14. 14 7月, 2008 1 次提交
    • I
      lockdep: fix ftrace irq tracing false positive · 992860e9
      Ingo Molnar 提交于
      fix this false positive:
      
      [    0.020000] ------------[ cut here ]------------
      [    0.020000] WARNING: at kernel/lockdep.c:2718 check_flags+0x14a/0x170()
      [    0.020000] Modules linked in:
      [    0.020000] Pid: 0, comm: swapper Not tainted 2.6.26-tip-00343-gd7e5521-dirty #14486
      [    0.020000]  [<c01312e4>] warn_on_slowpath+0x54/0x80
      [    0.020000]  [<c067e451>] ? _spin_unlock_irqrestore+0x61/0x70
      [    0.020000]  [<c0131bb1>] ? release_console_sem+0x201/0x210
      [    0.020000]  [<c0143d65>] ? __kernel_text_address+0x35/0x40
      [    0.020000]  [<c010562e>] ? dump_trace+0x5e/0x140
      [    0.020000]  [<c01518b5>] ? __lock_acquire+0x245/0x820
      [    0.020000]  [<c015063a>] check_flags+0x14a/0x170
      [    0.020000]  [<c0151ed8>] ? lock_acquire+0x48/0xc0
      [    0.020000]  [<c0151ee1>] lock_acquire+0x51/0xc0
      [    0.020000]  [<c014a16c>] ? down+0x2c/0x40
      [    0.020000]  [<c010a609>] ? sched_clock+0x9/0x10
      [    0.020000]  [<c067e7b2>] _write_lock+0x32/0x60
      [    0.020000]  [<c013797f>] ? request_resource+0x1f/0xb0
      [    0.020000]  [<c013797f>] request_resource+0x1f/0xb0
      [    0.020000]  [<c02f89ad>] vgacon_startup+0x2bd/0x3e0
      [    0.020000]  [<c094d62a>] con_init+0x19/0x22f
      [    0.020000]  [<c0330c7c>] ? tty_register_ldisc+0x5c/0x70
      [    0.020000]  [<c094cf49>] console_init+0x20/0x2e
      [    0.020000]  [<c092a969>] start_kernel+0x20c/0x379
      [    0.020000]  [<c092a516>] ? unknown_bootoption+0x0/0x1f6
      [    0.020000]  [<c092a099>] __init_begin+0x99/0xa1
      [    0.020000]  =======================
      [    0.020000] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.020000] possible reason: unannotated irqs-on.
      [    0.020000] irq event stamp: 0
      
      which occurs if CONFIG_TRACE_IRQFLAGS=y, CONFIG_DEBUG_LOCKDEP=y,
      but CONFIG_PROVE_LOCKING is disabled.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      992860e9
  15. 24 6月, 2008 1 次提交
  16. 20 6月, 2008 1 次提交
  17. 24 5月, 2008 4 次提交
    • S
      lockdep: update lockdep_recursion on graph_lock · bb065afb
      Steven Rostedt 提交于
      With the introduction of ftrace, it is possible to recurse into
      the lockdep functions via the mcount call. To prevent possible
      lockups, updating the lockdep_recursion counter on grabbing the internal
      lockdep_lock should prevent deadlocks.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bb065afb
    • S
      ftrace: use Makefile to remove tracing from lockdep · 1d09daa5
      Steven Rostedt 提交于
      This patch removes the "notrace" annotation from lockdep and adds the debugging
      files in the kernel director to those that should not be compiled with
      "-pg" mcount tracing.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1d09daa5
    • S
      ftrace: lockdep notrace annotations · 0764d23c
      Steven Rostedt 提交于
      Add notrace annotations to lockdep to keep ftrace from causing
      recursive problems with lock tracing and debugging.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      0764d23c
    • S
      ftrace: trace irq disabled critical timings · 81d68a96
      Steven Rostedt 提交于
      This patch adds latency tracing for critical timings
      (how long interrupts are disabled for).
      
       "irqsoff" is added to /debugfs/tracing/available_tracers
      
      Note:
        tracing_max_latency
          also holds the max latency for irqsoff (in usecs).
         (default to large number so one must start latency tracing)
      
        tracing_thresh
          threshold (in usecs) to always print out if irqs off
          is detected to be longer than stated here.
          If irq_thresh is non-zero, then max_irq_latency
          is ignored.
      
      Here's an example of a trace with ftrace_enabled = 0
      
      =======
      preemption latency trace v1.1.5 on 2.6.24-rc7
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      --------------------------------------------------------------------
       latency: 100 us, #3/3, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          -----------------
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
          -----------------
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
      
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1d.s3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1d.s3  100us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1d.s3  100us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      
      vim:ft=help
      =======
      
      And this is a trace with ftrace_enabled == 1
      
      =======
      preemption latency trace v1.1.5 on 2.6.24-rc7
      --------------------------------------------------------------------
       latency: 102 us, #12/12, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          -----------------
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
          -----------------
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
      
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1dNs3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_read_phy_reg+0x16/0x225 [e1000] (e1000_update_stats+0x5e2/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_swfw_sync_acquire+0x10/0x99 [e1000] (e1000_read_phy_reg+0x49/0x225 [e1000])
       swapper-0     1dNs3   46us : e1000_get_hw_eeprom_semaphore+0x12/0xa6 [e1000] (e1000_swfw_sync_acquire+0x36/0x99 [e1000])
       swapper-0     1dNs3   47us : __const_udelay+0x9/0x47 (e1000_read_phy_reg+0x116/0x225 [e1000])
       swapper-0     1dNs3   47us+: __delay+0x9/0x50 (__const_udelay+0x45/0x47)
       swapper-0     1dNs3   97us : preempt_schedule+0xc/0x84 (__delay+0x4e/0x50)
       swapper-0     1dNs3   98us : e1000_swfw_sync_release+0xc/0x55 [e1000] (e1000_read_phy_reg+0x211/0x225 [e1000])
       swapper-0     1dNs3   99us+: e1000_put_hw_eeprom_semaphore+0x9/0x35 [e1000] (e1000_swfw_sync_release+0x50/0x55 [e1000])
       swapper-0     1dNs3  101us : _spin_unlock_irqrestore+0xe/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      
      vim:ft=help
      =======
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      81d68a96
  18. 26 2月, 2008 1 次提交
  19. 26 1月, 2008 1 次提交
    • I
      softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks · 82a1fcb9
      Ingo Molnar 提交于
      this patch extends the soft-lockup detector to automatically
      detect hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are
      printed the following way:
      
       ------------------>
       INFO: task prctl:3042 blocked for more than 120 seconds.
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message
       prctl         D fd5e3793     0  3042   2997
              f6050f38 00000046 00000001 fd5e3793 00000009 c06d8264 c06dae80 00000286
              f6050f40 f6050f00 f7d34d90 f7d34fc8 c1e1be80 00000001 f6050000 00000000
              f7e92d00 00000286 f6050f18 c0489d1a f6050f40 00006605 00000000 c0133a5b
       Call Trace:
        [<c04883a5>] schedule_timeout+0x6d/0x8b
        [<c04883d8>] schedule_timeout_uninterruptible+0x15/0x17
        [<c0133a76>] msleep+0x10/0x16
        [<c0138974>] sys_prctl+0x30/0x1e2
        [<c0104c52>] sysenter_past_esp+0x5f/0xa5
        =======================
       2 locks held by prctl/3042:
       #0:  (&sb->s_type->i_mutex_key#5){--..}, at: [<c0197d11>] do_fsync+0x38/0x7a
       #1:  (jbd_handle){--..}, at: [<c01ca3d2>] journal_start+0xc7/0xe9
       <------------------
      
      the current default timeout is 120 seconds. Such messages are printed
      up to 10 times per bootup. If the system has crashed already then the
      messages are not printed.
      
      if lockdep is enabled then all held locks are printed as well.
      
      this feature is a natural extension to the softlockup-detector (kernel
      locked up without scheduling) and to the NMI watchdog (kernel locked up
      with IRQs disabled).
      
      [ Gautham R Shenoy <ego@in.ibm.com>: CPU hotplug fixes. ]
      [ Andrew Morton <akpm@linux-foundation.org>: build warning fix. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      82a1fcb9
  20. 25 1月, 2008 1 次提交
  21. 16 1月, 2008 1 次提交
  22. 08 12月, 2007 1 次提交
  23. 05 12月, 2007 2 次提交
    • O
      lockdep: in_range() fix · 54561783
      Oleg Nesterov 提交于
      Torsten Kaiser wrote:
      
      | static inline int in_range(const void *start, const void *addr, const void *end)
      | {
      |         return addr >= start && addr <= end;
      | }
      | This  will return true, if addr is in the range of start (including)
      | to end (including).
      |
      | But debug_check_no_locks_freed() seems does:
      | const void *mem_to = mem_from + mem_len
      | -> mem_to is the last byte of the freed range, that fits in_range
      | lock_from = (void *)hlock->instance;
      | -> first byte of the lock
      | lock_to = (void *)(hlock->instance + 1);
      | -> first byte of the next lock, not last byte of the lock that is being checked!
      |
      | The test is:
      | if (!in_range(mem_from, lock_from, mem_to) &&
      |                                         !in_range(mem_from, lock_to, mem_to))
      |                         continue;
      | So it tests, if the first byte of the lock is in the range that is freed ->OK
      | And if the first byte of the *next* lock is in the range that is freed
      | -> Not OK.
      
      We can also simplify in_range checks, we need only 2 comparisons, not 4.
      If the lock is not in memory range, it should be either at the left of range
      or at the right.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      54561783
    • I
      lockdep: fix debug_show_all_locks() · 85684873
      Ingo Molnar 提交于
      fix the oops that can be seen in:
      
         http://bugzilla.kernel.org/attachment.cgi?id=13828&action=view
      
      it is not safe to print the locks of running tasks.
      
      (even with this fix we have a small race - but this is a debug
       function after all.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      85684873
  24. 29 10月, 2007 1 次提交
  25. 20 10月, 2007 2 次提交
  26. 12 10月, 2007 2 次提交
  27. 20 7月, 2007 4 次提交
    • J
      lockdep debugging: give stacktrace for init_error · c71063c9
      Johannes Berg 提交于
      When I started adding support for lockdep to 64-bit powerpc, I got a
      lockdep_init_error and with this patch was able to pinpoint why and where
      to put lockdep_init().  Let's support this generally for others adding
      lockdep support to their architecture.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c71063c9
    • P
      lockstat: measure lock bouncing · 96645678
      Peter Zijlstra 提交于
          __acquire
              |
             lock _____
              |        \
              |    __contended
              |         |
              |        wait
              | _______/
              |/
              |
         __acquired
              |
         __release
              |
           unlock
      
      We measure acquisition and contention bouncing.
      
      This is done by recording a cpu stamp in each lock instance.
      
      Contention bouncing requires the cpu stamp to be set on acquisition. Hence we
      move __acquired into the generic path.
      
      __acquired is then used to measure acquisition bouncing by comparing the
      current cpu with the old stamp before replacing it.
      
      __contended is used to measure contention bouncing (only useful for preemptable
      locks)
      
      [akpm@linux-foundation.org: cleanups]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96645678
    • P
      lockdep: various fixes · 4b32d0a4
      Peter Zijlstra 提交于
       - update the copyright notices
       - use the default hash function
       - fix a thinko in a BUILD_BUG_ON
       - add a WARN_ON to spot inconsitent naming
       - fix a termination issue in /proc/lock_stat
      
      [akpm@linux-foundation.org: cleanups]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4b32d0a4
    • P
      lockstat: human readability tweaks · c46261de
      Peter Zijlstra 提交于
      Present all this fancy new lock statistics information:
      
      *warning, _wide_ output ahead*
      
      (output edited for purpose of brevity)
      
       # cat /proc/lock_stat
      lock_stat version 0.1
      -----------------------------------------------------------------------------------------------------------------------------------------------------------------
                                    class name    contentions   waittime-min   waittime-max waittime-total   acquisitions   holdtime-min   holdtime-max holdtime-total
      -----------------------------------------------------------------------------------------------------------------------------------------------------------------
      
                               &inode->i_mutex:         14458           6.57      398832.75     2469412.23        6768876           0.34    11398383.65   339410830.89
                               ---------------
                               &inode->i_mutex           4486          [<ffffffff802a08f9>] pipe_wait+0x86/0x8d
                               &inode->i_mutex              0          [<ffffffff802a01e8>] pipe_write_fasync+0x29/0x5d
                               &inode->i_mutex              0          [<ffffffff802a0e18>] pipe_read+0x74/0x3a5
                               &inode->i_mutex              0          [<ffffffff802a1a6a>] do_lookup+0x81/0x1ae
      
      .................................................................................................................................................................
      
                    &inode->i_data.tree_lock-W:           491           0.27          62.47         493.89        2477833           0.39         468.89     1146584.25
                    &inode->i_data.tree_lock-R:            65           0.44           4.27          48.78       26288792           0.36         184.62    10197458.24
                    --------------------------
                      &inode->i_data.tree_lock             46          [<ffffffff80277095>] __do_page_cache_readahead+0x69/0x24f
                      &inode->i_data.tree_lock             31          [<ffffffff8026f9fb>] add_to_page_cache+0x31/0xba
                      &inode->i_data.tree_lock              0          [<ffffffff802770ee>] __do_page_cache_readahead+0xc2/0x24f
                      &inode->i_data.tree_lock              0          [<ffffffff8026f6e4>] find_get_page+0x1a/0x58
      
      .................................................................................................................................................................
      
                            proc_inum_idr.lock:             0           0.00           0.00           0.00             36           0.00          65.60         148.26
                              proc_subdir_lock:             0           0.00           0.00           0.00        3049859           0.00         106.81     1563212.42
                              shrinker_rwsem-W:             0           0.00           0.00           0.00              5           0.00           1.73           3.68
                              shrinker_rwsem-R:             0           0.00           0.00           0.00            633           2.57         246.57       10909.76
      
      'contentions' and 'acquisitions' are the number of such events measured (since
      the last reset). The waittime- and holdtime- (min, max, total) numbers are
      presented in microseconds.
      
      If there are any contention points, the lock class is presented in the block
      format (as i_mutex and tree_lock above), otherwise a single line of output is
      presented.
      
      The output is sorted on absolute number of contentions (read + write), this
      should get the worst offenders presented first, so that:
      
       # grep : /proc/lock_stat | head
      
      will quickly show who's bad.
      
      The stats can be reset using:
      
       # echo 0 > /proc/lock_stat
      
      [bunk@stusta.de: make 2 functions static]
      [akpm@linux-foundation.org: fix printk warning]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c46261de