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
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.
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
* 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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo