Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

rcu: Documentation update

This commit applies a few updates based on a quick review of the RCU
documentations.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

+35 -11
+16 -10
Documentation/RCU/checklist.txt
··· 217 217 whether the increased speed is worth it. 218 218 219 219 8. Although synchronize_rcu() is slower than is call_rcu(), it 220 - usually results in simpler code. So, unless update performance 221 - is critically important or the updaters cannot block, 222 - synchronize_rcu() should be used in preference to call_rcu(). 220 + usually results in simpler code. So, unless update performance is 221 + critically important, the updaters cannot block, or the latency of 222 + synchronize_rcu() is visible from userspace, synchronize_rcu() 223 + should be used in preference to call_rcu(). Furthermore, 224 + kfree_rcu() usually results in even simpler code than does 225 + synchronize_rcu() without synchronize_rcu()'s multi-millisecond 226 + latency. So please take advantage of kfree_rcu()'s "fire and 227 + forget" memory-freeing capabilities where it applies. 223 228 224 229 An especially important property of the synchronize_rcu() 225 230 primitive is that it automatically self-limits: if grace periods ··· 273 268 e. Periodically invoke synchronize_rcu(), permitting a limited 274 269 number of updates per grace period. 275 270 276 - The same cautions apply to call_rcu_bh() and call_rcu_sched(). 271 + The same cautions apply to call_rcu_bh(), call_rcu_sched(), 272 + call_srcu(), and kfree_rcu(). 277 273 278 274 9. All RCU list-traversal primitives, which include 279 275 rcu_dereference(), list_for_each_entry_rcu(), and ··· 302 296 all currently executing rcu_read_lock()-protected RCU read-side 303 297 critical sections complete. It does -not- necessarily guarantee 304 298 that all currently running interrupts, NMIs, preempt_disable() 305 - code, or idle loops will complete. Therefore, if you do not have 306 - rcu_read_lock()-protected read-side critical sections, do -not- 307 - use synchronize_rcu(). 299 + code, or idle loops will complete. Therefore, if your 300 + read-side critical sections are protected by something other 301 + than rcu_read_lock(), do -not- use synchronize_rcu(). 308 302 309 303 Similarly, disabling preemption is not an acceptable substitute 310 304 for rcu_read_lock(). Code that attempts to use preemption ··· 407 401 read-side critical sections. It is the responsibility of the 408 402 RCU update-side primitives to deal with this. 409 403 410 - 17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and 411 - the __rcu sparse checks to validate your RCU code. These 412 - can help find problems as follows: 404 + 17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the 405 + __rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to 406 + validate your RCU code. These can help find problems as follows: 413 407 414 408 CONFIG_PROVE_RCU: check that accesses to RCU-protected data 415 409 structures are carried out under the proper RCU
+5
Documentation/RCU/lockdep.txt
··· 64 64 but retain the compiler constraints that prevent duplicating 65 65 or coalescsing. This is useful when when testing the 66 66 value of the pointer itself, for example, against NULL. 67 + rcu_access_index(idx): 68 + Return the value of the index and omit all barriers, but 69 + retain the compiler constraints that prevent duplicating 70 + or coalescsing. This is useful when when testing the 71 + value of the index itself, for example, against -1. 67 72 68 73 The rcu_dereference_check() check expression can be any boolean 69 74 expression, but would normally include a lockdep expression. However,
+14 -1
Documentation/RCU/rcubarrier.txt
··· 79 79 2. Execute rcu_barrier(). 80 80 3. Allow the module to be unloaded. 81 81 82 - The rcutorture module makes use of rcu_barrier in its exit function 82 + There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier() 83 + functions for the other flavors of RCU, and you of course must match 84 + the flavor of rcu_barrier() with that of call_rcu(). If your module 85 + uses multiple flavors of call_rcu(), then it must also use multiple 86 + flavors of rcu_barrier() when unloading that module. For example, if 87 + it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on 88 + srcu_struct_2(), then the following three lines of code will be required 89 + when unloading: 90 + 91 + 1 rcu_barrier_bh(); 92 + 2 srcu_barrier(&srcu_struct_1); 93 + 3 srcu_barrier(&srcu_struct_2); 94 + 95 + The rcutorture module makes use of rcu_barrier() in its exit function 83 96 as follows: 84 97 85 98 1 static void