public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox