Documentation/RCU/rcu_dereference.rst

113 	can now be speculated, such that it might happen before the
195 	might provide, especially if you are making use of feedback-based
260 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
261 but you should not be.  After all, the updater might have been invoked
333 first pointer might be.  This lack of knowledge prevents the compiler
334 from carrying out optimizations that otherwise might destroy the ordering
338 But without rcu_dereference(), the compiler knows more than you might
400 2.	If the access might be within an RCU read-side critical section
408 3.	If the access might be within an RCU read-side critical section
427 	is appropriate.  In addition, rcu_dereference_raw() might be
429 	complex, except that a better approach in that case might be to
436 	might expect given the number of uses in the current kernel.
453 If register pressure is high, the compiler might optimize "p" out
465 of pointers, which also might fatally disappoint your code.
480 and friends.  For example, ->rcu_protected_pointer might be declared as