Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency

[Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>]

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.

Best wishes,
   jonas