Merge tag 'soc-for-linus-3' of git://git.kernel.org/pub/scm/linux/kernel/git/arm...

[GitHub/mt8127/android_kernel_alcatel_ttab.git] / Documentation / RCU / checklist.txt

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 31ef8fe07f828026ad31f29e63bdd95143bf3e2a..79e789b8b8ea22d680463a531a3e3d9990adb8ba 100644 (file)
--- 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