Merge branches 'bigrt.2012.09.23a', 'doctorture.2012.09.23a',...

	code under the influence of preempt_disable(), you instead

	need to use synchronize_irq() or synchronize_sched().

	This same limitation also applies to synchronize_rcu_bh()

	and synchronize_srcu(), as well as to the asynchronous and

	expedited forms of the three primitives, namely call_rcu(),

	call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),

	synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().

12.	Any lock acquired by an RCU callback must be acquired elsewhere

	with softirq disabled, e.g., via spin_lock_irqsave(),

	spin_lock_bh(), etc.  Failing to disable irq on a given

printed:

	INFO: rcu_preempt detected stall on CPU

	0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1

	0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending

	   (t=65000 jiffies)

The "(64628 ticks this GP)" indicates that this CPU has taken more

be a small positive number if in the idle loop and a very large positive

number (as shown above) otherwise.

For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the

CPU is not in the process of trying to force itself into dyntick-idle

state, the "." indicates that the CPU has not given up forcing RCU

into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"

indicates that the CPU has not recented forced RCU into dyntick-idle

mode (it would otherwise indicate the number of microseconds remaining

in this forced state).

For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is

not in the process of trying to force itself into dyntick-idle state, the

"." indicates that the CPU has not given up forcing RCU into dyntick-idle

mode (it would be "H" otherwise), and the "timer not pending" indicates

that the CPU has not recently forced RCU into dyntick-idle mode (it

would otherwise indicate the number of microseconds remaining in this

forced state).

Multiple Warnings From One Stall

	and code segments with preemption disabled (whether

	via preempt_disable(), local_irq_save(), local_bh_disable(),

	or some other mechanism) as if they were explicit RCU readers?

	If so, you need RCU-sched.

	If so, RCU-sched is the only choice that will work for you.

e.	Do you need RCU grace periods to complete even in the face

	of softirq monopolization of one or more of the CPUs?  For

	RCU, but inappropriate for other synchronization mechanisms?

	If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!

g.	Otherwise, use RCU.

g.	Do you need read-side critical sections that are respected

	even though they are in the middle of the idle loop, during

	user-mode execution, or on an offlined CPU?  If so, SRCU is the

	only choice that will work for you.

h.	Otherwise, use RCU.

Of course, this all assumes that you have determined that RCU is in fact

the right tool for your job.

#include <linux/tty.h>

#include <linux/console.h>

#include <linux/slab.h>

#include <linux/rcupdate.h>

#include <asm/reg.h>

#include <asm/uaccess.h>

		/* FIXME -- EV6 and LCA45 know how to power down

		   the CPU.  */

		rcu_idle_enter();

		while (!need_resched())

			cpu_relax();

		schedule();

		rcu_idle_exit();

		schedule_preempt_disabled();

	}

}

	DBGS(("smp_callin: commencing CPU %d current %p active_mm %p\n",

	      cpuid, current, current->active_mm));

	preempt_disable();

	/* Do nothing.  */

	cpu_idle();

}