Merge branches 'torture.2014.11.03a', 'cpu.2014.11.03a', 'doc.2014.11.13a',...

	executed in user mode, or executed in the idle loop, we can

	safely free up that item.

	Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the

	Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the

	same effect, but require that the readers manipulate CPU-local

	counters.  These counters allow limited types of blocking within

	RCU read-side critical sections.  SRCU also uses CPU-local

o	I hear that RCU needs work in order to support realtime kernels?

	This work is largely completed.  Realtime-friendly RCU can be

	enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration

	enabled via the CONFIG_PREEMPT_RCU kernel configuration

	parameter.  However, work is in progress for enabling priority

	boosting of preempted RCU read-side critical sections.	This is

	needed if you have CPU-bound realtime threads.

	Stall-warning messages may be enabled and disabled completely via

	/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.

CONFIG_RCU_CPU_STALL_VERBOSE

	This kernel configuration parameter causes the stall warning to

	also dump the stacks of any tasks that are blocking the current

	RCU-preempt grace period.

CONFIG_RCU_CPU_STALL_INFO

	This kernel configuration parameter causes the stall warning to

and that the stall was affecting RCU-sched.  This message will normally be

followed by a stack dump of the offending CPU.  On TREE_RCU kernel builds,

RCU and RCU-sched are implemented by the same underlying mechanism,

while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented

while on PREEMPT_RCU kernel builds, RCU is instead implemented

by rcu_preempt_state.

On the other hand, if the offending CPU fails to print out a stall-warning

This message indicates that CPU 2 detected that CPUs 3 and 5 were both

causing stalls, and that the stall was affecting RCU-bh.  This message

will normally be followed by stack dumps for each CPU.  Please note that

TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,

PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,

and that the tasks will be indicated by PID, for example, "P3421".

It is even possible for a rcu_preempt_state stall to be caused by both

CPUs -and- tasks, in which case the offending CPUs and tasks will all

o	A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that

	is running at a higher priority than the RCU softirq threads.

	This will prevent RCU callbacks from ever being invoked,

	and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent

	and in a CONFIG_PREEMPT_RCU kernel will further prevent

	RCU grace periods from ever completing.  Either way, the

	system will eventually run out of memory and hang.  In the

	CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning

	CONFIG_PREEMPT_RCU case, you might see stall-warning

	messages.

o	A hardware or software issue shuts off the scheduler-clock

for rcutree and next for rcutiny.

CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats

CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats

These implementations of RCU provide several debugfs directories under the

top-level directory "rcu":

rcu/rcu_sched

Each directory contains files for the corresponding flavor of RCU.

Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.

Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.

For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,

so that activity for both appears in rcu/rcu_sched.

	Used by a reader to inform the reclaimer that the reader is

	entering an RCU read-side critical section.  It is illegal

	to block while in an RCU read-side critical section, though

	kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU

	kernels built with CONFIG_PREEMPT_RCU can preempt RCU

	read-side critical sections.  Any RCU-protected data structure

	accessed during an RCU read-side critical section is guaranteed to

	remain unreclaimed for the full duration of that critical section.

maintainers on how to implement atomic counter, bitops, and spinlock

interfaces properly.

	The atomic_t type should be defined as a signed integer.

Also, it should be made opaque such that any kind of cast to a normal

C integer type will fail.  Something like the following should

suffice:

	The atomic_t type should be defined as a signed integer and

the atomic_long_t type as a signed long integer.  Also, they should

be made opaque such that any kind of cast to a normal C integer type

will fail.  Something like the following should suffice:

	typedef struct { int counter; } atomic_t;

	typedef struct { long counter; } atomic_long_t;

Historically, counter has been declared volatile.  This is now discouraged.

See Documentation/volatile-considered-harmful.txt for the complete rationale.

proper implicit or explicit read memory barrier is needed before reading the

value with atomic_read from another thread.

As with all of the atomic_ interfaces, replace the leading "atomic_"

with "atomic_long_" to operate on atomic_long_t.

The second interface can be used at runtime, as in:

	struct foo { atomic_t counter; };