On Sat, Sep 28, 2024 at 11:55:22AM -0400, Mathieu Desnoyers wrote:
On 2024-09-28 17:49, Alan Stern wrote:
Isn't it true that on strongly ordered CPUs, a compiler barrier is
sufficient to prevent the rcu_dereference() problem? So the whole idea
behind ptr_eq() is that it prevents the problem on all CPUs.
Correct. But given that we have ptr_eq(), it's good to show how it
equally prevents the compiler from reordering address-dependent loads
(comparison with constant) *and* prevents the compiler from using
one pointer rather than the other (comparison between two non-constant
pointers) which affects speculation on weakly-ordered CPUs.
I don't see how these two things differ from each other. In the
comparison-with-a-constant case, how is the compiler reordering
anything? Isn't it just using the constant address rather than the
loaded pointer and thereby breaking the address dependency?