Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

* 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (64 commits)
  cpu: Export cpu_up()
  rcu: Apply ACCESS_ONCE() to rcu_boost() return value
  Revert "rcu: Permit rt_mutex_unlock() with irqs disabled"
  docs: Additional LWN links to RCU API
  rcu: Augment rcu_batch_end tracing for idle and callback state
  rcu: Add rcutorture tests for srcu_read_lock_raw()
  rcu: Make rcutorture test for hotpluggability before offlining CPUs
  driver-core/cpu: Expose hotpluggability to the rest of the kernel
  rcu: Remove redundant rcu_cpu_stall_suppress declaration
  rcu: Adaptive dyntick-idle preparation
  rcu: Keep invoking callbacks if CPU otherwise idle
  rcu: Irq nesting is always 0 on rcu_enter_idle_common
  rcu: Don't check irq nesting from rcu idle entry/exit
  rcu: Permit dyntick-idle with callbacks pending
  rcu: Document same-context read-side constraints
  rcu: Identify dyntick-idle CPUs on first force_quiescent_state() pass
  rcu: Remove dynticks false positives and RCU failures
  rcu: Reduce latency of rcu_prepare_for_idle()
  rcu: Eliminate RCU_FAST_NO_HZ grace-period hang
  rcu: Avoid needlessly IPIing CPUs at GP end
  ...

6 files changed, 48 insertions, 20 deletions

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 0c134f8afc6f..bff2d8be1e18 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -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"
diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt
index 31852705b586..bf778332a28f 100644
--- a/Documentation/RCU/rcu.txt
+++ b/Documentation/RCU/rcu.txt
@@ -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?
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 4e959208f736..083d88cbc089 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -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.
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 783d6c134d3f..d67068d0d2b9 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -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.
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index aaf65f6c6cd7..49587abfc2f7 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -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
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 6ef692667e2f..6bbe8dcdc3da 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -4,6 +4,7 @@ to start learning about RCU:
 1.      What is RCU, Fundamentally?  http://lwn.net/Articles/262464/
 2.      What is RCU? Part 2: Usage   http://lwn.net/Articles/263130/
 3.      RCU part 3: the RCU API      http://lwn.net/Articles/264090/
+4.      The RCU API, 2010 Edition    http://lwn.net/Articles/418853/
 
 
 What is RCU?
@@ -834,6 +835,8 @@ 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_unlock_raw
         srcu_dereference
 
 SRCU:   Initialization/cleanup
@@ -855,27 +858,33 @@ list can be helpful:
 
 a.      Will readers need to block?  If so, you need SRCU.
 
-b.      What about the -rt patchset?  If readers would need to block
+b.      Is it necessary to start a read-side critical section in a
+        hardirq handler or exception handler, and then to complete
+        this read-side critical section in the task that was
+        interrupted?  If so, you need SRCU's srcu_read_lock_raw() and
+        srcu_read_unlock_raw() primitives.
+
+c.      What about the -rt patchset?  If readers would need to block
         in an non-rt kernel, you need SRCU.  If readers would block
         in a -rt kernel, but not in a non-rt kernel, SRCU is not
         necessary.
 
-c.      Do you need to treat NMI handlers, hardirq handlers,
+d.      Do you need to treat NMI handlers, hardirq handlers,
         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.
 
-d.      Do you need RCU grace periods to complete even in the face
+e.      Do you need RCU grace periods to complete even in the face
         of softirq monopolization of one or more of the CPUs?  For
         example, is your code subject to network-based denial-of-service
         attacks?  If so, you need RCU-bh.
 
-e.      Is your workload too update-intensive for normal use of
+f.      Is your workload too update-intensive for normal use of
         RCU, but inappropriate for other synchronization mechanisms?
         If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!
 
-f.      Otherwise, use RCU.
+g.      Otherwise, use RCU.
 
 Of course, this all assumes that you have determined that RCU is in fact
 the right tool for your job.