On Mon, Sep 30, 2024 at 11:42:11AM +0200, Jonas Oberhauser wrote: > > > Am 9/28/2024 um 11:15 PM schrieb Alan Stern: > > 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? > > I also currently don't see any major difference between the constant and > register case. The point is that the address is known before loading into b, > and hence the compiler + hardware can speculatively load *b before loading > into b. > > The only difference is how far before loading into b the address is known. In theory, true. In practice, in the register case, you need a little more bad luck for the compiler to be able to exploit your mistake. Still, it is indeed far better to attain a state of bliss by keeping the compiler ignorant. Thanx, Paul
