Document the fact that RCU callbacks can run in parallel
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Mon, 16 Jul 2007 06:41:03 +0000 (23:41 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Mon, 16 Jul 2007 16:05:47 +0000 (09:05 -0700)
Add an item to the RCU documentation checklist noting that RCU callbacks
can run in parallel.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Documentation/RCU/checklist.txt

index f4dffadbcb00af44b40b99dd55649731b57cb21d..42b01bc2e1b4f01f414b340a6204fb3ea1087953 100644 (file)
@@ -222,7 +222,15 @@ over a rather long period of time, but improvements are always welcome!
        deadlock as soon as the RCU callback happens to interrupt that
        acquisition's critical section.
 
-13.    SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
+13.    RCU callbacks can be and are executed in parallel.  In many cases,
+       the callback code simply wrappers around kfree(), so that this
+       is not an issue (or, more accurately, to the extent that it is
+       an issue, the memory-allocator locking handles it).  However,
+       if the callbacks do manipulate a shared data structure, they
+       must use whatever locking or other synchronization is required
+       to safely access and/or modify that data structure.
+
+14.    SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
        may only be invoked from process context.  Unlike other forms of
        RCU, it -is- permissible to block in an SRCU read-side critical
        section (demarked by srcu_read_lock() and srcu_read_unlock()),