Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Steven Rostedt
On Wed, 2013-02-06 at 08:58 -0800, Ben Greear wrote: > > One of many. All those "goto out;"s skip the rcu_read_unlock(). > > Thank you so much! You're welcome ;-) > > I'll fix this and continue testing... > > I can also post a patch to print the held locks when > the max-lock-depth overflows

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Ben Greear
On 02/06/2013 08:07 AM, Steven Rostedt wrote: On Wed, 2013-02-06 at 07:56 -0800, Ben Greear wrote: I'm 99% sure that the bug is in your modifications. I'm sorry, I tried to make that clear. You said it was an out of tree module, I didn't realize it had changes to the core Linux as well.

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Steven Rostedt
On Wed, 2013-02-06 at 17:39 +0100, Ingo Molnar wrote: > * Steven Rostedt wrote: > Wondering whether we could improve lockdep to detect 'excessive' > lock nesting and treat it as a bug - the 'ran out of lockdep > entries' assert might be too detached and it might even trigger > in innocent, low

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Ingo Molnar
* Steven Rostedt wrote: > On Wed, 2013-02-06 at 07:56 -0800, Ben Greear wrote: > > > > I'm 99% sure that the bug is in your modifications. > > > > I'm sorry, I tried to make that clear. > > You said it was an out of tree module, I didn't realize it had changes > to the core Linux as well. >

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Steven Rostedt
On Wed, 2013-02-06 at 07:56 -0800, Ben Greear wrote: > > I'm 99% sure that the bug is in your modifications. > > I'm sorry, I tried to make that clear. You said it was an out of tree module, I didn't realize it had changes to the core Linux as well. > My tree is here, minus a few debugging pat

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Ben Greear
On 02/06/2013 05:21 AM, Steven Rostedt wrote: On Tue, 2013-02-05 at 22:23 -0800, Ben Greear wrote: On 02/05/2013 08:36 PM, Steven Rostedt wrote: On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote: It's huge, so here's a link: http://www.candelatech.com/~greearb/debug.tgz The trace shows

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-06 Thread Steven Rostedt
On Tue, 2013-02-05 at 22:23 -0800, Ben Greear wrote: > On 02/05/2013 08:36 PM, Steven Rostedt wrote: > > On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote: > > > >> It's huge, so here's a link: > >> > >> http://www.candelatech.com/~greearb/debug.tgz > >> > > > > The trace shows that __netif_recei

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
On 02/05/2013 08:36 PM, Steven Rostedt wrote: On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote: It's huge, so here's a link: http://www.candelatech.com/~greearb/debug.tgz The trace shows that __netif_receive_skb() is grabbing an rcu_read_lock() but never releasing it. But I don't see any

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
On 02/05/2013 08:26 PM, Steven Rostedt wrote: On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote: === [ INFO: suspicious RCU usage. ] 3.7.6+ #4 Tainted: G C O --- /home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360 Ille

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Steven Rostedt
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote: > It's huge, so here's a link: > > http://www.candelatech.com/~greearb/debug.tgz > The trace shows that __netif_receive_skb() is grabbing an rcu_read_lock() but never releasing it. But I don't see any possible way that can be true in the code

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Steven Rostedt
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote: > > > === > [ 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

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
On 02/05/2013 06:52 PM, Steven Rostedt wrote: On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote: Well, here it is..something is calling rcu_read_lock lots and lots, Or a bug in the way lockdep handles rcu mappings. it seems. Any way to get a better idea of where those calls are made? Ye

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Steven Rostedt
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote: > Well, here it is..something is calling rcu_read_lock lots and lots, Or a bug in the way lockdep handles rcu mappings. > it seems. Any way to get a better idea of where those calls are > made? Yeah, with ftrace. > 96 locks held by swapper/0

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
On 02/05/2013 05:54 PM, Steven Rostedt wrote: On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote: 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

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
On 02/05/2013 05:54 PM, Steven Rostedt wrote: I'm not sure the swapper task is part of the 'do_each_thread()' loop. Perhaps what you want to do is add a: lockdep_print_held_locks(current); I'll add that and test... I'm curious. Does your code grab a read lock? If you grab the same

Re: Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Steven Rostedt
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote: > 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_DEP

Question on lockdep and MAX_LOCK_DEPTH

2013-02-05 Thread Ben Greear
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