Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 51aa7827 authored by Paul E. McKenney's avatar Paul E. McKenney
Browse files

Merge branch 'rcu/fixes-for-v3.2' into rcu/urgent 



Merge reason: Add these commits so that fixes on this branch do not
	conflict with already-mainlined code.

Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parents 805a6af8 a513f6ba

Documentation/RCU/checklist.txt

+6 −0
Original line number Diff line number Diff line
@@ -328,6 +328,12 @@ over a rather long period of time, but improvements are always welcome! 
	RCU rather than SRCU, because RCU is almost always faster and

	easier to use than is SRCU.



	If you need to enter your read-side critical section in a

	hardirq or exception handler, and then exit that same read-side

	critical section in the task that was interrupted, then you need

	to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid

	the lockdep checking that would otherwise this practice illegal.



	Also unlike other forms of RCU, explicit initialization

	and cleanup is required via init_srcu_struct() and

	cleanup_srcu_struct().	These are passed a "struct srcu_struct"

Documentation/RCU/rcu.txt

+5 −5
Original line number Diff line number Diff line
@@ -38,11 +38,11 @@ o How can the updater tell when a grace period has completed 


	Preemptible variants of RCU (CONFIG_TREE_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 counters, and permits general blocking within

	RCU read-side critical sections.  These two variants of

	RCU detect grace periods by sampling these counters.

	counters.  These counters allow limited types of blocking within

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

	counters, and permits general blocking within RCU read-side

	critical sections.  These variants of RCU detect grace periods

	by sampling these counters.



o	If I am running on a uniprocessor kernel, which can only do one

	thing at a time, why should I wait for a grace period?

Documentation/RCU/stallwarn.txt

+10 −6
Original line number Diff line number Diff line
@@ -101,6 +101,11 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that 
	CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning

	messages.



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

	interrupt on a CPU that is not in dyntick-idle mode.  This

	problem really has happened, and seems to be most likely to

	result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.



o	A bug in the RCU implementation.



o	A hardware failure.  This is quite unlikely, but has occurred
@@ -109,12 +114,11 @@ o A hardware failure. This is quite unlikely, but has occurred 
	This resulted in a series of RCU CPU stall warnings, eventually

	leading the realization that the CPU had failed.



The RCU, RCU-sched, and RCU-bh implementations have CPU stall

warning.  SRCU does not have its own CPU stall warnings, but its

calls to synchronize_sched() will result in RCU-sched detecting

RCU-sched-related CPU stalls.  Please note that RCU only detects

CPU stalls when there is a grace period in progress.  No grace period,

no CPU stall warnings.

The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.

SRCU does not have its own CPU stall warnings, but its calls to

synchronize_sched() will result in RCU-sched detecting RCU-sched-related

CPU stalls.  Please note that RCU only detects CPU stalls when there is

a grace period in progress.  No grace period, no CPU stall warnings.



To diagnose the cause of the stall, inspect the stack traces.

The offending function will usually be near the top of the stack.

Documentation/RCU/torture.txt

+13 −0
Original line number Diff line number Diff line
@@ -61,11 +61,24 @@ nreaders This is the number of RCU reading threads supported. 
		To properly exercise RCU implementations with preemptible

		read-side critical sections.



onoff_interval

		The number of seconds between each attempt to execute a

		randomly selected CPU-hotplug operation.  Defaults to

		zero, which disables CPU hotplugging.  In HOTPLUG_CPU=n

		kernels, rcutorture will silently refuse to do any

		CPU-hotplug operations regardless of what value is

		specified for onoff_interval.



shuffle_interval

		The number of seconds to keep the test threads affinitied

		to a particular subset of the CPUs, defaults to 3 seconds.

		Used in conjunction with test_no_idle_hz.



shutdown_secs	The number of seconds to run the test before terminating

		the test and powering off the system.  The default is

		zero, which disables test termination and system shutdown.

		This capability is useful for automated testing.



stat_interval	The number of seconds between output of torture

		statistics (via printk()).  Regardless of the interval,

		statistics are printed when the module is unloaded.

Documentation/RCU/trace.txt

+0 −4
Original line number Diff line number Diff line
@@ -105,14 +105,10 @@ o "dt" is the current value of the dyntick counter that is incremented 
	or one greater than the interrupt-nesting depth otherwise.

	The number after the second "/" is the NMI nesting depth.



	This field is displayed only for CONFIG_NO_HZ kernels.



o	"df" is the number of times that some other CPU has forced a

	quiescent state on behalf of this CPU due to this CPU being in

	dynticks-idle state.



	This field is displayed only for CONFIG_NO_HZ kernels.



o	"of" is the number of times that some other CPU has forced a

	quiescent state on behalf of this CPU due to this CPU being

	offline.  In a perfect world, this might never happen, but it