# Re: \[v3,11/41\] mips: reuse asm-generic/barrier.h

- From: Linus Torvalds \<torvalds@linux-foundation.org\>
- Date: 2016-01-26 19:44:54 
- List: linuxppc-dev
- Page: https://ratatoskr.run/linuxppc-dev/2016/01/4669499
- Thread: https://ratatoskr.run/sparclinux/2016/01/4656797/t/2.md

```text
On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra [ref] wrot=
e:
>
> This is distinct from:

That may be distinct, but:

>         struct foo *x =3D READ_ONCE(*ptr);
>         smp_read_barrier_depends();
>         x->bar =3D 5;

This case is complete BS. Stop perpetuating it. I already removed a
number of bogus cases of it, and I removed the incorrect documentation
that had this crap.

It's called "smp_READ_barrier_depends()" for a reason.

Alpha is the only one that needs it, and alpha needs it only for
dependent READS.

It's not called smp_read_write_barrier_depends(). It's not called
"smp_mb_depends()". It's a weaker form of "smp_rmb()", nothing else.

So alpha does have an implied dependency chain from a read to a
subsequent dependent write, and does not need any extra barriers.

Alpha does *not* have a dependency chain from a read to a subsequent
read, which is why we need that horrible crappy
smp_read_barrier_depends(). But it's the only reason.

This is the alpha reference manual wrt read-to-write dependency:

  5.6.1.7 Definition of Dependence Constraint

    The depends relation (DP) is defined as follows. Given u and v
issued by processor Pi, where u
    is a read or an instruction fetch and v is a write, u precedes v
in DP order (written u DP v, that
    is, v depends on u) in either of the following situations:

     =E2=80=A2 u determines the execution of v, the location accessed by v,=
 or
the value written by v.
     =E2=80=A2 u determines the execution or address or value of another
memory access z that precedes

    v or might precede v (that is, would precede v in some execution
path depending
    on the value read by u) by processor issue constraint (see Section 5.6.=
1.3).

Note that the dependence barrier honors not only control flow, but
address and data values too.  This is a different syntax than we use,
but 'u' is the READ_ONCE, and 'v' is the write. Any data, address or
conditional dependency between the two implies an ordering.

So no, "smp_read_barrier_depends()" is *ONLY* about two reads, where
the second read is data-dependent on the first. Nothing else.

So if you _ever_ see a "smp_read_barrier_depends()" that isn't about a
barrier between two reads, then that is a bug.

The above code is crap.  It's exactly as much crap as

   a =3D READ_ONCE(x);
   smp_rmb();
   WRITE_ONCE(b, y);

because a "rmb()" simply doesn't have anything to do with
read-vs-subsequent-write ordering.

                 Linus
```