Merge branch 'rcu/next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu

Pull the RCU tree from Paul E. McKenney:

"The major features of this series are:

1.	Preventing latency spikes of more than 200 microseconds for
	kernels built with NR_CPUS=4096, which is reportedly becoming
	the default for some distros.  This is a first step, as it does
	not help with systems that actually -have- 4096 CPUs (work on
	this case is in progress, but is not yet ready for mainline).
	This category also includes improving concurrency of rcu_barrier(),
	placed here due to conflicts.  Posted to LKML at:
	https://lkml.org/lkml/2012/6/22/381.  Note that patches 18-22
	of that series have been defered to 3.7, as they have not yet
	proven themselves to be mainline-ready (and yes, these are the
	ones intended to get rid of RCU's latency spikes for systems
	that actually have 4096 CPUs).
2.	Updates to documentation and rcutorture fixes, the latter category
	including improvements to rcu_barrier() testing.  Posted to LKML at:
	http://lkml.indiana.edu/hypermail/linux/kernel/1206.1/04094.html.
3.	Miscellaneous fixes posted to LKML at:
	https://lkml.org/lkml/2012/6/22/500, with the exception of the
	last commit, which was posted here:
	http://www.gossamer-threads.com/lists/linux/kernel/1561830
4.	RCU_FAST_NO_HZ fixes and improvements.  Posted to LKML at:
	http://lkml.indiana.edu/hypermail/linux/kernel/1206.1/00006.html
	and http://www.gossamer-threads.com/lists/linux/kernel/1561833.
	The first four patches of the first series went into 3.5 to fix
	a regression.
5.	Code-style fixes.  These were posted to LKML at
	http://lkml.indiana.edu/hypermail/linux/kernel/1205.2/01180.html and
	http://lkml.indiana.edu/hypermail/linux/kernel/1205.2/01181.html.
"

Signed-off-by: Ingo Molnar <mingo@kernel.org>

5 files changed, 41 insertions, 33 deletions

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 5c8d74968090..fc103d7a0474 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome!
                 when publicizing a pointer to a structure that can
                 be traversed by an RCU read-side critical section.
 
-5.      If call_rcu(), or a related primitive such as call_rcu_bh() or
-        call_rcu_sched(), is used, the callback function must be
-        written to be called from softirq context.  In particular,
+5.      If call_rcu(), or a related primitive such as call_rcu_bh(),
+        call_rcu_sched(), or call_srcu() is used, the callback function
+        must be written to be called from softirq context.  In particular,
         it cannot block.
 
 6.      Since synchronize_rcu() can block, it cannot be called from
@@ -202,11 +202,12 @@ over a rather long period of time, but improvements are always welcome!
         updater uses call_rcu_sched() or synchronize_sched(), then
         the corresponding readers must disable preemption, possibly
         by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
-        If the updater uses synchronize_srcu(), the the corresponding
-        readers must use srcu_read_lock() and srcu_read_unlock(),
-        and with the same srcu_struct.  The rules for the expedited
-        primitives are the same as for their non-expedited counterparts.
-        Mixing things up will result in confusion and broken kernels.
+        If the updater uses synchronize_srcu() or call_srcu(),
+        the the corresponding readers must use srcu_read_lock() and
+        srcu_read_unlock(), and with the same srcu_struct.  The rules for
+        the expedited primitives are the same as for their non-expedited
+        counterparts.  Mixing things up will result in confusion and
+        broken kernels.
 
         One exception to this rule: rcu_read_lock() and rcu_read_unlock()
         may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
@@ -333,14 +334,14 @@ over a rather long period of time, but improvements are always welcome!
         victim CPU from ever going offline.)
 
 14.     SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),
-        synchronize_srcu(), and synchronize_srcu_expedited()) may only
-        be invoked from process context.  Unlike other forms of RCU, it
-        -is- permissible to block in an SRCU read-side critical section
-        (demarked by srcu_read_lock() and srcu_read_unlock()), hence the
-        "SRCU": "sleepable RCU".  Please note that if you don't need
-        to sleep in read-side critical sections, you should be using
-        RCU rather than SRCU, because RCU is almost always faster and
-        easier to use than is SRCU.
+        synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())
+        may only be invoked from process context.  Unlike other forms of
+        RCU, it -is- permissible to block in an SRCU read-side critical
+        section (demarked by srcu_read_lock() and srcu_read_unlock()),
+        hence the "SRCU": "sleepable RCU".  Please note that if you
+        don't need to sleep in read-side critical sections, you should be
+        using 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
@@ -353,8 +354,8 @@ over a rather long period of time, but improvements are always welcome!
         cleanup_srcu_struct().  These are passed a "struct srcu_struct"
         that defines the scope of a given SRCU domain.  Once initialized,
         the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
-        synchronize_srcu(), and synchronize_srcu_expedited().  A given
-        synchronize_srcu() waits only for SRCU read-side critical
+        synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().
+        A given synchronize_srcu() waits only for SRCU read-side critical
         sections governed by srcu_read_lock() and srcu_read_unlock()
         calls that have been passed the same srcu_struct.  This property
         is what makes sleeping read-side critical sections tolerable --
@@ -374,7 +375,7 @@ over a rather long period of time, but improvements are always welcome!
         requiring SRCU's read-side deadlock immunity or low read-side
         realtime latency.
 
-        Note that, rcu_assign_pointer() relates to SRCU just as they do
+        Note that, rcu_assign_pointer() relates to SRCU just as it does
         to other forms of RCU.
 
 15.     The whole point of call_rcu(), synchronize_rcu(), and friends
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index e439a0edee22..38428c125135 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows:
    2. Execute rcu_barrier().
    3. Allow the module to be unloaded.
 
-Quick Quiz #1: Why is there no srcu_barrier()?
-
 The rcutorture module makes use of rcu_barrier in its exit function
 as follows:
 
@@ -162,7 +160,7 @@ for any pre-existing callbacks to complete.
 Then lines 55-62 print status and do operation-specific cleanup, and
 then return, permitting the module-unload operation to be completed.
 
-Quick Quiz #2: Is there any other situation where rcu_barrier() might
+Quick Quiz #1: Is there any other situation where rcu_barrier() might
         be required?
 
 Your module might have additional complications. For example, if your
@@ -242,7 +240,7 @@ reaches zero, as follows:
  4 complete(&rcu_barrier_completion);
  5 }
 
-Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
+Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
         immediately (thus incrementing rcu_barrier_cpu_count to the
         value one), but the other CPU's rcu_barrier_func() invocations
         are delayed for a full grace period? Couldn't this result in
@@ -259,12 +257,7 @@ so that your module may be safely unloaded.
 
 Answers to Quick Quizzes
 
-Quick Quiz #1: Why is there no srcu_barrier()?
-
-Answer: Since there is no call_srcu(), there can be no outstanding SRCU
-        callbacks. Therefore, there is no need to wait for them.
-
-Quick Quiz #2: Is there any other situation where rcu_barrier() might
+Quick Quiz #1: Is there any other situation where rcu_barrier() might
         be required?
 
 Answer: Interestingly enough, rcu_barrier() was not originally
@@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
         implementing rcutorture, and found that rcu_barrier() solves
         this problem as well.
 
-Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
+Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
         immediately (thus incrementing rcu_barrier_cpu_count to the
         value one), but the other CPU's rcu_barrier_func() invocations
         are delayed for a full grace period? Couldn't this result in
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 4ddf3913fd8c..7dce8a17eac2 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -174,11 +174,20 @@ torture_type	The type of RCU to test, with string values as follows:
                         and synchronize_rcu_bh_expedited().
 
                 "srcu": srcu_read_lock(), srcu_read_unlock() and
+                        call_srcu().
+
+                "srcu_sync": srcu_read_lock(), srcu_read_unlock() and
                         synchronize_srcu().
 
                 "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
                         synchronize_srcu_expedited().
 
+                "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
+                        and call_srcu().
+
+                "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
+                        and synchronize_srcu().
+
                 "sched": preempt_disable(), preempt_enable(), and
                         call_rcu_sched().
 
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 6bbe8dcdc3da..69ee188515e7 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -833,9 +833,9 @@ sched:	Critical sections	Grace period		Barrier
 
 SRCU:   Critical sections       Grace period            Barrier
 
-        srcu_read_lock          synchronize_srcu        N/A
-        srcu_read_unlock        synchronize_srcu_expedited
-        srcu_read_lock_raw
+        srcu_read_lock          synchronize_srcu        srcu_barrier
+        srcu_read_unlock        call_srcu
+        srcu_read_lock_raw      synchronize_srcu_expedited
         srcu_read_unlock_raw
         srcu_dereference
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a92c5ebf373e..12783fa833c3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2367,6 +2367,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Set maximum number of finished RCU callbacks to process
                         in one batch.
 
+        rcutree.fanout_leaf=    [KNL,BOOT]
+                        Increase the number of CPUs assigned to each
+                        leaf rcu_node structure.  Useful for very large
+                        systems.
+
         rcutree.qhimark=        [KNL,BOOT]
                         Set threshold of queued
                         RCU callbacks over which batch limiting is disabled.