All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ben Greear <greearb@candelatech.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: Question on lockdep and MAX_LOCK_DEPTH
Date: Wed, 6 Feb 2013 17:39:17 +0100	[thread overview]
Message-ID: <20130206163917.GA15403@gmail.com> (raw)
In-Reply-To: <1360166840.2621.45.camel@gandalf.local.home>


* 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

  reply	other threads:[~2013-02-06 16:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06  1:10 Question on lockdep and MAX_LOCK_DEPTH Ben Greear
2013-02-06  1:54 ` 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 [this message]
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=20130206163917.GA15403@gmail.com \
    --to=mingo@kernel.org \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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.