public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Jones <davej@codemonkey.org.uk>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Stephane Eranian <eranian@gmail.com>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: perf related lockdep bug
Date: Wed, 4 Nov 2015 07:51:10 -0800	[thread overview]
Message-ID: <20151104155110.GW29027@linux.vnet.ibm.com> (raw)
In-Reply-To: <20151104153651.GC11639@twins.programming.kicks-ass.net>

On Wed, Nov 04, 2015 at 04:36:51PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 04, 2015 at 03:20:58PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 04, 2015 at 05:48:38AM -0800, Paul E. McKenney wrote:
> > > This problem is caused by the IPI handler interrupting the RCU read-side
> > > critical section.  One way to prevent the IPI from doing this is to
> > > disable interrupts across the RCU read-side critical section instead
> > > of merely disabling preemption.  This is a reasonable approach given
> > > that acquiring the scheduler locks is going to disable interrupts
> > > in any case.
> > > 
> > > The (untested) patch below takes this approach.
> > > 
> > > Thoughts?
> > 
> > Yes, this should work, but now I worry I need to go audit all of perf
> > and sched for this :/
> 
> I can't find any other sites just now, so let me queue this.

Works for me, thank you!  It passes light rcutorture testing, but then
again so did the version without this commit.  :-/

I will queue the needed documentation updates separately.  I don't see
these as urgent, so probably next merge window.

> I also had a brief look if you used any other locks under rnp->lock, but
> aside from the printk and sched things it seems clean.

Whew!  ;-)

							Thanx, Paul


  reply	other threads:[~2015-11-04 15:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04  5:17 perf related lockdep bug Dave Jones
2015-11-04 10:21 ` Peter Zijlstra
2015-11-04 10:28   ` Peter Zijlstra
2015-11-04 10:50     ` Peter Zijlstra
2015-11-04 13:48       ` Paul E. McKenney
2015-11-04 14:20         ` Peter Zijlstra
2015-11-04 15:34           ` Paul E. McKenney
2015-11-04 15:36           ` Peter Zijlstra
2015-11-04 15:51             ` Paul E. McKenney [this message]
2015-11-04 20:58         ` Andi Kleen
2015-11-05  0:55           ` Paul E. McKenney
2015-11-05  1:59             ` Paul E. McKenney
2015-11-05  2:46             ` Andi Kleen
2015-11-05 14:04               ` Paul E. McKenney
2015-11-11 13:29                 ` Paul E. McKenney
2015-11-10  6:39         ` [tip:perf/urgent] perf: Disable IRQs across RCU RS CS that acquires scheduler lock tip-bot for Paul E. McKenney
2015-11-04 14:01     ` perf related lockdep bug Paul E. McKenney
2015-11-04 14:34       ` Peter Zijlstra
2015-11-05  1:57         ` Paul E. McKenney

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=20151104155110.GW29027@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=davej@codemonkey.org.uk \
    --cc=eranian@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox