Documentation/RCU/rcu_dereference.rst

126 	can now be speculated, such that it might happen before the
208 	might provide, especially if you are making use of feedback-based
273 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
274 but you should not be.  After all, the updater might have been invoked
346 first pointer might be.  This lack of knowledge prevents the compiler
347 from carrying out optimizations that otherwise might destroy the ordering
351 But without rcu_dereference(), the compiler knows more than you might
413 2.	If the access might be within an RCU read-side critical section
421 3.	If the access might be within an RCU read-side critical section
440 	is appropriate.  In addition, rcu_dereference_raw() might be
442 	complex, except that a better approach in that case might be to
449 	might expect given the number of uses in the current kernel.
466 If register pressure is high, the compiler might optimize "p" out
478 of pointers, which also might fatally disappoint your code.
493 and friends.  For example, ->rcu_protected_pointer might be declared as