1 files changed, 16 insertions, 10 deletions

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 31ef8fe07f82..79e789b8b8ea 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
         whether the increased speed is worth it.
 
 8.      Although synchronize_rcu() is slower than is call_rcu(), it
-        usually results in simpler code.  So, unless update performance
-        is critically important or the updaters cannot block,
-        synchronize_rcu() should be used in preference to call_rcu().
+        usually results in simpler code.  So, unless update performance is
+        critically important, the updaters cannot block, or the latency of
+        synchronize_rcu() is visible from userspace, synchronize_rcu()
+        should be used in preference to call_rcu().  Furthermore,
+        kfree_rcu() usually results in even simpler code than does
+        synchronize_rcu() without synchronize_rcu()'s multi-millisecond
+        latency.  So please take advantage of kfree_rcu()'s "fire and
+        forget" memory-freeing capabilities where it applies.
 
         An especially important property of the synchronize_rcu()
         primitive is that it automatically self-limits: if grace periods
@@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
         e.      Periodically invoke synchronize_rcu(), permitting a limited
                 number of updates per grace period.
 
-        The same cautions apply to call_rcu_bh() and call_rcu_sched().
+        The same cautions apply to call_rcu_bh(), call_rcu_sched(),
+        call_srcu(), and kfree_rcu().
 
 9.      All RCU list-traversal primitives, which include
         rcu_dereference(), list_for_each_entry_rcu(), and
@@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
         all currently executing rcu_read_lock()-protected RCU read-side
         critical sections complete.  It does -not- necessarily guarantee
         that all currently running interrupts, NMIs, preempt_disable()
-        code, or idle loops will complete.  Therefore, if you do not have
-        rcu_read_lock()-protected read-side critical sections, do -not-
-        use synchronize_rcu().
+        code, or idle loops will complete.  Therefore, if your
+        read-side critical sections are protected by something other
+        than rcu_read_lock(), do -not- use synchronize_rcu().
 
         Similarly, disabling preemption is not an acceptable substitute
         for rcu_read_lock().  Code that attempts to use preemption
@@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
         read-side critical sections.  It is the responsibility of the
         RCU update-side primitives to deal with this.
 
-17.     Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
-        the __rcu sparse checks to validate your RCU code.  These
-        can help find problems as follows:
+17.     Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
+        __rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
+        validate your RCU code.  These can help find problems as follows:
 
         CONFIG_PROVE_RCU: check that accesses to RCU-protected data
                 structures are carried out under the proper RCU