rcu: Update docs for rcu_access_pointer and rcu_dereference_protected

Update examples and lists of APIs to include these new
primitives.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
Cc: eric.dumazet@gmail.com
LKML-Reference: <1270852752-25278-3-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

1 files changed, 4 insertions, 3 deletions

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index cbc180f90194..790d1a812376 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -260,7 +260,8 @@ over a rather long period of time, but improvements are always welcome!
         The reason that it is permissible to use RCU list-traversal
         primitives when the update-side lock is held is that doing so
         can be quite helpful in reducing code bloat when common code is
-        shared between readers and updaters.
+        shared between readers and updaters.  Additional primitives
+        are provided for this case, as discussed in lockdep.txt.
 
 10.     Conversely, if you are in an RCU read-side critical section,
         and you don't hold the appropriate update-side lock, you -must-
@@ -344,8 +345,8 @@ 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() and rcu_dereference() relate to
-        SRCU just as they do to other forms of RCU.
+        Note that, rcu_assign_pointer() relates 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