All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Will Simoneau <simoneau@ele.uri.edu>
Cc: linux-kernel@vger.kernel.org, dipankar@in.ibm.com
Subject: Re: 2.6.39.4: Oops in rcu_read_unlock_special()/_raw_spin_lock()
Date: Thu, 25 Aug 2011 14:40:45 -0700	[thread overview]
Message-ID: <20110825214045.GJ2369@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110825182819.GA6874@ele.uri.edu>

On Thu, Aug 25, 2011 at 02:28:19PM -0400, Will Simoneau wrote:
> On 07:07 Thu 25 Aug     , Paul E. McKenney wrote:
> > On Thu, Aug 25, 2011 at 09:20:51AM -0400, Will Simoneau wrote:
> > > On 14:27 Wed 24 Aug     , Paul E. McKenney wrote:
> > > > On Wed, Aug 24, 2011 at 05:19:07PM -0400, Will Simoneau wrote:
> > > > > The following commits from Linus' git seem vaguely related,
> > > > > although I have no idea how relevant they are to 2.6.39.4:
> > > > > 
> > > > >    ec433f0c (softirq,rcu: Inform RCU of irq_exit() activity)
> > > > >    10f39bb1 (rcu: protect __rcu_read_unlock() against scheduler-using
> > > > >              irq handlers)
> > > > 
> > > > If this failure mechanism really is the culprit, you should be able
> > > > to make failure happen much more frequently by inserting a delay in
> > > > __rcu_read_unlock() just prior to the call to rcu_read_unlock_special().
> > > > I would suggest starting with a few tens to hundreds of microseconds
> > > > worth of delay.
> > > > 
> > > > If this does make the failure reproducible, then it would make sense
> > > > to try applying the two patches you identified.
> > > 
> > > Hmm. I tried adding progressively larger delays in the spot you
> > > indicated. I went from 100uS to an entire 1S (!) and got no crash or
> > > deadlock. The target runs at 40MHz so the delays do need to be
> > > relatively long compared to modern machines.
> > > 
> > > My hardware breakpoint as well as printk tests confirm that
> > > rcu_read_unlock_special() really does get called multiple times per
> > > second, and the 1S delay makes it painfully obvious as well. But, no
> > > dice.
> > 
> > Well, you can always apply the two patches above anyway, but it is hard
> > to prove what the underlying problem really is in your case.
> 
> I am still unable to reproduce the Oops so I have no way of knowing if
> applying the patches has any effect. I did find and fix the issue with
> booting post-2.6.39* kernels on my hardware, so I've moved on to
> 3.1-rc3. I guess I will get back to you if it happens again :-)

Fair enough!  ;-)

							Thanx, Paul

      reply	other threads:[~2011-08-25 21:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-24 21:19 2.6.39.4: Oops in rcu_read_unlock_special()/_raw_spin_lock() Will Simoneau
2011-08-24 21:27 ` Paul E. McKenney
2011-08-25 13:20   ` Will Simoneau
2011-08-25 14:07     ` Paul E. McKenney
2011-08-25 18:28       ` Will Simoneau
2011-08-25 21:40         ` Paul E. McKenney [this message]

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=20110825214045.GJ2369@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simoneau@ele.uri.edu \
    /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.