On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
> On 2024-09-28 16:49, Alan Stern wrote:
> > On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
> > > equality, which does not preserve address dependencies and allows the
> > > following misordering speculations:
> > >
> > > - If @b is a constant, the compiler can issue the loads which depend
> > > on @a before loading @a.
> > > - If @b is a register populated by a prior load, weakly-ordered
> > > CPUs can speculate loads which depend on @a before loading @a.
> >
> > It shouldn't matter whether @a and @b are constants, registers, or
> > anything else. All that matters is that the compiler uses the wrong
> > one, which allows weakly ordered CPUs to speculate loads you wouldn't
> > expect it to, based on the source code alone.
>
> I only partially agree here.
>
> On weakly-ordered architectures, indeed we don't care whether the
> issue is caused by the compiler reordering the code (constant)
> or the CPU speculating the load (registers).
>
> However, on strongly-ordered architectures, AFAIU, only the constant
> case is problematic (compiler reordering the dependent load), because
I thought you were trying to prevent the compiler from using one pointer
instead of the other, not trying to prevent it from reordering anything.
Isn't this the point the documentation wants to get across when it says
that comparing pointers can be dangerous?
> CPU speculating the loads across the control dependency is not an
> issue.
>
> So am I tempted to keep examples that clearly state whether
> the issue is caused by compiler reordering instructions, or by
> CPU speculation.
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.
You can make your examples as specific as you like, but the fact remains
that ptr_eq() is meant to prevent situations where both:
The compiler uses the wrong pointer for a load, and
The CPU performs the load earlier than you want.
If either one of those doesn't hold then the problem won't arise.
Alan Stern
