From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030445AbbKDPvQ (ORCPT ); Wed, 4 Nov 2015 10:51:16 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:38515 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932323AbbKDPvP (ORCPT ); Wed, 4 Nov 2015 10:51:15 -0500 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Wed, 4 Nov 2015 07:51:10 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Dave Jones , Linux Kernel , Ingo Molnar , Stephane Eranian , Andi Kleen Subject: Re: perf related lockdep bug Message-ID: <20151104155110.GW29027@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151104051717.GA6098@codemonkey.org.uk> <20151104102151.GG17308@twins.programming.kicks-ass.net> <20151104102800.GZ11639@twins.programming.kicks-ass.net> <20151104105010.GA11639@twins.programming.kicks-ass.net> <20151104134838.GR29027@linux.vnet.ibm.com> <20151104142058.GX3604@twins.programming.kicks-ass.net> <20151104153651.GC11639@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151104153651.GC11639@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15110415-0005-0000-0000-0000198AA422 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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