Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

From	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Newsgroups	linux.kernel
Subject	Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Date	2016-01-31 01:30 +0100
Message-ID	<qWO3U-3pb-11@gated-at.bofh.it> (permalink)
References	(5 earlier) <qR9ur-4CR-33@gated-at.bofh.it> <qRjWO-3cE-3@gated-at.bofh.it> <qRkSS-3Rl-3@gated-at.bofh.it> <qRlOV-4t7-3@gated-at.bofh.it> <qWj9L-553-11@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected Peter Zijlstra <peterz@infradead.org> - 2016-01-29 16:30 +0100
  Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-31 01:30 +0100

csiph-web