All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Question on lockdep and MAX_LOCK_DEPTH
Date: Tue, 05 Feb 2013 17:10:37 -0800	[thread overview]
Message-ID: <5111AD8D.1080005@candelatech.com> (raw)

I'm debugging something that could be my own bug in my wanlink module (but then
again, haven't seen this on 3.5 kernels, and my module is
basically un-changed since then).

I'm using lockdep, and keep seeing "BUG: MAX_LOCK_DEPTH too low".
I tried changing the depth to 96 from 48, but it still hits.

I also added debug_show_all_locks(); when this error
case hits.  I was assuming that if lockdep depth is large,
there would be lots of locks held..but that does not
seem to be the case??



===============================
[ INFO: suspicious RCU usage. ]
3.7.6+ #4 Tainted: G         C O
-------------------------------
/home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360 Illegal idle entry in RCU read-side critical section.!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/1/0:
  #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff81489632>] rcu_read_lock+0x0/0x6f

stack backtrace:
Pid: 0, comm: swapper/1 Tainted: G         C O 3.7.6+ #4
Call Trace:
  <IRQ>  [<ffffffff810cecbd>] lockdep_rcu_suspicious+0xfc/0x105
  [<ffffffff810fe146>] rcu_eqs_enter_common+0xef/0x178
  [<ffffffff810fe24e>] rcu_irq_exit+0x7f/0xb0
  [<ffffffff8108edf5>] irq_exit+0xc0/0xcc
  [<ffffffff8100b635>] do_IRQ+0x97/0xae
  [<ffffffff815543b2>] common_interrupt+0x72/0x72
  <EOI>  [<ffffffff81011082>] ? mwait_idle+0x77/0x9f
  [<ffffffff81011079>] ? mwait_idle+0x6e/0x9f
  [<ffffffff81011379>] cpu_idle+0x68/0xbc
  [<ffffffff8154ce84>] start_secondary+0x1fc/0x203

Showing all locks held in the system:
1 lock held by bash/2481:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2853:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2857:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2862:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2865:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2867:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by mingetty/2869:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785
1 lock held by bash/3017:
  #0:  (&tty->atomic_read_lock){+.+...}, at: [<ffffffff813400a3>] n_tty_read+0x28d/0x785

=============================================

BUG: MAX_LOCK_DEPTH too low, depth: 96  max: 96!
turning off the locking correctness validator.
Pid: 0, comm: swapper/1 Tainted: G         C O 3.7.6+ #4
Call Trace:
  <IRQ>  [<ffffffff810d1e31>] __lock_acquire+0xe80/0xf06
  [<ffffffff810cfbbe>] ? check_irq_usage+0xad/0xbe
  [<ffffffff810d1f1b>] lock_acquire+0x64/0x81
  [<ffffffff810acbf3>] ? cpu_cgroup_can_attach+0x66/0x66
  [<ffffffff810acc26>] rcu_read_lock+0x33/0x6f
  [<ffffffff810acbf3>] ? cpu_cgroup_can_attach+0x66/0x66
  [<ffffffff810ad1a8>] ttwu_stat+0x60/0x11c
  [<ffffffff810b1cbb>] try_to_wake_up+0x1e6/0x20b
  [<ffffffff810b1ced>] default_wake_function+0xd/0xf
  [<ffffffff810ab4c1>] __wake_up_common+0x49/0x7f
  [<ffffffff810ac4e5>] __wake_up+0x34/0x48
  [<ffffffffa05fce11>] handleRcvWlp+0xf4d/0xfd5 [wanlink]
  [<ffffffff810d133a>] ? __lock_acquire+0x389/0xf06
  [<ffffffffa05fd325>] wp_handle_rcv_pkt+0x1f5/0x243 [wanlink]
  [<ffffffffa05fd51c>] handle_rcv+0x1a9/0x1dd [wanlink]
  [<ffffffff8148a5f1>] deliver_skb+0x58/0x60
  [<ffffffff8148ab00>] __netif_receive_skb+0x507/0x63c
  [<ffffffff810100b6>] ? read_tsc+0x9/0x1b
  [<ffffffff8148c939>] netif_receive_skb+0x56/0x8b
  [<ffffffff8148cf64>] ? __napi_gro_receive+0xf3/0x102
  [<ffffffff8148ca51>] napi_skb_finish+0x24/0x57
  [<ffffffff8148d199>] napi_gro_receive+0x91/0x96
  [<ffffffffa0231d31>] e1000_receive_skb+0x50/0x5b [e1000e]
  [<ffffffffa023500c>] e1000_clean_rx_irq+0x29f/0x341 [e1000e]
  [<ffffffffa02355c6>] e1000e_poll+0x7d/0x239 [e1000e]
  [<ffffffff8148d31f>] net_rx_action+0xb2/0x1e2
  [<ffffffff8108eeea>] ? __do_softirq+0x6d/0x17b
  [<ffffffff8108ef28>] __do_softirq+0xab/0x17b
  [<ffffffff810a6ed6>] ? hrtimer_interrupt+0x127/0x1e2
  [<ffffffff8155a7fc>] call_softirq+0x1c/0x30
  [<ffffffff8100bd46>] do_softirq+0x46/0x9e
  [<ffffffff8108ed83>] irq_exit+0x4e/0xcc
  [<ffffffff81027f73>] smp_apic_timer_interrupt+0x85/0x93
  [<ffffffff8155a0b2>] apic_timer_interrupt+0x72/0x80
  <EOI>  [<ffffffff81554477>] ? retint_restore_args+0x13/0x13
  [<ffffffff81011082>] ? mwait_idle+0x77/0x9f
  [<ffffffff81011079>] ? mwait_idle+0x6e/0x9f
  [<ffffffff81011379>] cpu_idle+0x68/0xbc
  [<ffffffff8154ce84>] start_secondary+0x1fc/0x203
BUG: sleeping function called from invalid context at /home/greearb/git/linux-3.7.dev.y/kernel/mutex.c:269
in_atomic(): 0, irqs_disabled(): 0, pid: 1375, name: rs:main Q:Reg
INFO: lockdep is turned off.
Pid: 1375, comm: rs:main Q:Reg Tainted: G         C O 3.7.6+ #4
Call Trace:
  [<ffffffff810adc9d>] __might_sleep+0x1a2/0x1ab
  [<ffffffff81551969>] mutex_lock_nested+0x20/0x3b
  [<ffffffff8133e243>] process_output+0x24/0x52
  [<ffffffff8133fba3>] n_tty_write+0x273/0x356
  [<ffffffff810b1ce0>] ? try_to_wake_up+0x20b/0x20b
  [<ffffffff8133db38>] tty_write+0x19b/0x23a
  [<ffffffff8133f930>] ? n_tty_ioctl+0xc6/0xc6
  [<ffffffff8133dc61>] redirected_tty_write+0x8a/0x95
  [<ffffffff81158d6c>] vfs_write+0xa9/0x105
  [<ffffffff81158ead>] sys_write+0x54/0x89
  [<ffffffff81559569>] system_call_fastpath+0x16/0x1b

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


             reply	other threads:[~2013-02-06  1:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06  1:10 Ben Greear [this message]
2013-02-06  1:54 ` Question on lockdep and MAX_LOCK_DEPTH Steven Rostedt
2013-02-06  2:17   ` Ben Greear
2013-02-06  2:26   ` Ben Greear
2013-02-06  2:52     ` Steven Rostedt
2013-02-06  3:30       ` Ben Greear
2013-02-06  4:36         ` Steven Rostedt
2013-02-06  6:23           ` Ben Greear
2013-02-06 13:21             ` Steven Rostedt
2013-02-06 15:56               ` Ben Greear
2013-02-06 16:07                 ` Steven Rostedt
2013-02-06 16:39                   ` Ingo Molnar
2013-02-06 16:46                     ` Steven Rostedt
2013-02-06 16:58                   ` Ben Greear
2013-02-06 17:03                     ` Steven Rostedt
2013-02-06  4:26 ` Steven Rostedt
2013-02-06  6:20   ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5111AD8D.1080005@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.