]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commit
timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop
authorPreeti U Murthy <preeti@linux.vnet.ibm.com>
Wed, 18 Mar 2015 10:49:27 +0000 (16:19 +0530)
committerIngo Molnar <mingo@kernel.org>
Mon, 23 Mar 2015 09:50:05 +0000 (10:50 +0100)
commita127d2bcf1fbc8c8e0b5cf0dab54f7d3ff50ce47
treeba7b28d14f48b4f190b96401fe96cdec682e828b
parentbc465aa9d045feb0e13b4a8f32cc33c1943f62d6
timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop

The hrtimer mode of broadcast queues hrtimers in the idle entry
path so as to wakeup cpus in deep idle states. The associated
call graph is :

cpuidle_idle_call()
|____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....))
     |_____tick_broadcast_set_event()
   |____clockevents_program_event()
|____bc_set_next()

The hrtimer_{start/cancel} functions call into tracing which uses RCU.
But it is not legal to call into RCU in cpuidle because it is one of the
quiescent states. Hence protect this region with RCU_NONIDLE which informs
RCU that the cpu is momentarily non-idle.

As an aside it is helpful to point out that the clock event device that is
programmed here is not a per-cpu clock device; it is a
pseudo clock device, used by the broadcast framework alone.
The per-cpu clock device programming never goes through bc_set_next().

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Cc: mpe@ellerman.id.au
Cc: tglx@linutronix.de
Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/time/tick-broadcast-hrtimer.c