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

From	Peter Zijlstra <peterz@infradead.org>
Newsgroups	linux.kernel
Subject	Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Date	2016-01-29 16:30 +0100
Message-ID	<qWj9L-553-11@gated-at.bofh.it> (permalink)
References	(5 earlier) <qR1Gz-7or-17@gated-at.bofh.it> <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>
Organization	linux.* mail to news gateway

Show all headers | View raw

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 :-)

Back to linux.kernel | Previous | Next — Next 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