diff options
author | Jason A. Donenfeld <Jason@zx2c4.com> | 2015-08-11 12:26:33 (GMT) |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2015-10-06 18:22:43 (GMT) |
commit | 2c4ac34bc2d97f056ed3c43fa03c0737fae46fb6 (patch) | |
tree | e0a0fd8523214a4e3fe653e8b74c2d85013f0398 /Documentation/RCU/torture.txt | |
parent | da873def8da5883a6c04d11f73dcd836c216cf4f (diff) | |
download | linux-2c4ac34bc2d97f056ed3c43fa03c0737fae46fb6.tar.xz |
documentation: Correct doc to use rcu_dereference_protected
As there is lots of misinformation and outdated information on the
Internet about nearly all topics related to the kernel, I thought it
would be best if I based my RCU code on the guidelines of the examples
in the Documentation/ tree of the latest kernel. One thing that stuck
out when reading the whatisRCU.txt document was, "interesting how we
don't need any function to dereference rcu protected pointers when doing
updates if a lock is held. I wonder how static analyzers will work with
that." Then, a few weeks later, upon discovering sparse's __rcu support,
I ran it over my code, and lo and behold, things weren't done right.
Examining other RCU usages in the kernel reveal consistent usage of
rcu_dereference_protected, passing in lockdep_is_held as the
conditional. So, this patch adds that idiom to the documentation, so
that others ahead of me won't endure the same exercise.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Diffstat (limited to 'Documentation/RCU/torture.txt')
0 files changed, 0 insertions, 0 deletions