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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzcC6C8imPs5vk4yH1Y2YHjnAdFM9HCkVs04COxuDQH6w@mail.gmail.com>
Date:	Tue, 26 Jan 2016 11:44:46 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Boqun Feng <boqun.feng@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	linux-mips <linux-mips@...ux-mips.org>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Will Deacon <will.deacon@....com>,
	virtualization <virtualization@...ts.linux-foundation.org>,
	Peter Anvin <hpa@...or.com>, sparclinux@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	linux-s390 <linux-s390@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	uml-devel <user-mode-linux-devel@...ts.sourceforge.net>,
	linux-sh@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	xen-devel@...ts.xenproject.org, Ingo Molnar <mingo@...e.hu>,
	linux-xtensa@...ux-xtensa.org,
	James Hogan <james.hogan@...tec.com>,
	Arnd Bergmann <arnd@...db.de>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	adi-buildroot-devel@...ts.sourceforge.net,
	David Daney <ddaney.cavm@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-metag@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Joe Perches <joe@...ches.com>,
	ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> This is distinct from:

That may be distinct, but:

>         struct foo *x = READ_ONCE(*ptr);
>         smp_read_barrier_depends();
>         x->bar = 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:

     • u determines the execution of v, the location accessed by v, or
the value written by v.
     • 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 = 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