4 files changed, 18 insertions, 6 deletions

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 6e253407b3dc..accfe2f5247d 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -298,3 +298,15 @@ over a rather long period of time, but improvements are always welcome!
 
         Note that, rcu_assign_pointer() and rcu_dereference() relate to
         SRCU just as they do to other forms of RCU.
+
+15.     The whole point of call_rcu(), synchronize_rcu(), and friends
+        is to wait until all pre-existing readers have finished before
+        carrying out some otherwise-destructive operation.  It is
+        therefore critically important to -first- remove any path
+        that readers can follow that could be affected by the
+        destructive operation, and -only- -then- invoke call_rcu(),
+        synchronize_rcu(), or friends.
+
+        Because these primitives only wait for pre-existing readers,
+        it is the caller's responsibility to guarantee safety to
+        any subsequent readers.
diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt
index 1fd175368a87..4349c1487e91 100644
--- a/Documentation/RCU/listRCU.txt
+++ b/Documentation/RCU/listRCU.txt
@@ -118,7 +118,7 @@ Following are the RCU equivalents for these two functions:
                 list_for_each_entry(e, list, list) {
                         if (!audit_compare_rule(rule, &e->rule)) {
                                 list_del_rcu(&e->list);
-                                call_rcu(&e->rcu, audit_free_rule, e);
+                                call_rcu(&e->rcu, audit_free_rule);
                                 return 0;
                         }
                 }
@@ -206,7 +206,7 @@ RCU ("read-copy update") its name.  The RCU code is as follows:
                                 ne->rule.action = newaction;
                                 ne->rule.file_count = newfield_count;
                                 list_replace_rcu(e, ne);
-                                call_rcu(&e->rcu, audit_free_rule, e);
+                                call_rcu(&e->rcu, audit_free_rule);
                                 return 0;
                         }
                 }
@@ -283,7 +283,7 @@ flag under the spinlock as follows:
                                 list_del_rcu(&e->list);
                                 e->deleted = 1;
                                 spin_unlock(&e->lock);
-                                call_rcu(&e->rcu, audit_free_rule, e);
+                                call_rcu(&e->rcu, audit_free_rule);
                                 return 0;
                         }
                 }
diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt
index 95821a29ae41..7aa2002ade77 100644
--- a/Documentation/RCU/rcu.txt
+++ b/Documentation/RCU/rcu.txt
@@ -81,7 +81,7 @@ 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_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
+        preempted RCU read-side critical sections.  This is needed if you
         have CPU-bound realtime threads.
 
 o       Where can I find more information on RCU?
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 239f542d48ba..6389dec33459 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -21,7 +21,7 @@ if (obj) {
   /*
    * Because a writer could delete object, and a writer could
    * reuse these object before the RCU grace period, we
-   * must check key after geting the reference on object
+   * must check key after getting the reference on object
    */
   if (obj->key != key) { // not the object we expected
      put_ref(obj);
@@ -117,7 +117,7 @@ a race (some writer did a delete and/or a move of an object
 to another chain) checking the final 'nulls' value if
 the lookup met the end of chain. If final 'nulls' value
 is not the slot number, then we must restart the lookup at
-the begining. If the object was moved to same chain,
+the beginning. If the object was moved to the same chain,
 then the reader doesnt care : It might eventually
 scan the list again without harm.