Messages in this thread |  | | Date | Wed, 6 Feb 2013 17:39:17 +0100 | From | Ingo Molnar <> | Subject | Re: Question on lockdep and MAX_LOCK_DEPTH |
| |
* Steven Rostedt <rostedt@goodmis.org> 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. > > > My tree is here, minus a few debugging patches related to > > this bug: > > > > http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.7.dev.y/.git;a=summary > > Here's your bug: > > 3319 list_for_each_entry_rcu(ptype, &ptype_all, list) { > 3320 if (!ptype->dev || ptype->dev == skb->dev) { > 3321 if (pt_prev) { > 3322 ret = deliver_skb(skb, pt_prev, orig_dev); > 3323 if (ret == NET_RX_CONSUMED) { > 3324 kfree_skb(skb); /* we made a copy in deliver_skb */ > 3325 goto out; > 3326 } > 3327 } > > One of many. All those "goto out;"s skip the rcu_read_unlock().
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 lesting count contexts.
Thanks,
Ingo
|  |