From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932650AbcAaA2d (ORCPT <rfc822;w@1wt.eu>);
	Sat, 30 Jan 2016 19:28:33 -0500
Received: from e31.co.us.ibm.com ([32.97.110.149]:33959 "EHLO
	e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932134AbcAaA2c (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Jan 2016 19:28:32 -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: Sat, 30 Jan 2016 16:28:25 -0800
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Sasha Levin <sasha.levin@oracle.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Message-ID: <20160131002825.GJ6719@linux.vnet.ibm.com>
Reply-To: paulmck@linux.vnet.ibm.com
References: <20160113161608.GN3818@linux.vnet.ibm.com>
 <alpine.DEB.2.11.1601141812270.3575@nanos>
 <20160114181846.GZ3818@linux.vnet.ibm.com>
 <alpine.DEB.2.11.1601142036260.3575@nanos>
 <20160115014232.GQ3818@linux.vnet.ibm.com>
 <alpine.DEB.2.11.1601151102320.3575@nanos>
 <20160115211125.GA3818@linux.vnet.ibm.com>
 <20160115221045.GA8598@linux.vnet.ibm.com>
 <20160115231410.GA16973@linux.vnet.ibm.com>
 <20160129152735.GB407@worktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160129152735.GB407@worktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 16013100-8236-0000-0000-000015A95690
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jan 29, 2016 at 04:27:35PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 15, 2016 at 03:14:10PM -0800, Paul E. McKenney wrote:
> > And if I make the scheduling-clock interrupt send extra wakeups to the RCU
> > grace-period kthread when needed, things work even with CPU hotplug going.
> > 
> > The "when needed" means any time that the RCU grace-period kthread has
> > been sleeping three times as long as the timeout interval.  If the first
> > wakeup does nothing, it does another wakeup once per second.
> > 
> > So it looks like this change makes an existing problem much worse, as
> > opposed to introducing a new problem.
> 
> I have a vague idea about a possible race window. Have you been
> observing this on PPC or x86?
> 
> The reason I'm asking is that PPC (obviously) allows for more races :-)

;-)

I have been seeing this on x86.

							Thanx, Paul