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: <20160126201037.GU4503@linux.vnet.ibm.com>
Date:	Tue, 26 Jan 2016 12:10:37 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Boqun Feng <boqun.feng@...il.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 11:44:46AM -0800, Linus Torvalds wrote:
> 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.

If I understand your objection correctly, you want the above pattern
expressed either like this:

	struct foo *x = rcu_dereference(*ptr);
	x->bar = 5;

Or like this:

	struct foo *x = lockless_dereference(*ptr);
	x->bar = 5;

Or am I missing your point?

> 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.

And the smp_read_barrier_depends() in both rcu_dereference() and
in lockless_dereference() is ordering the read-to-read case and the
underlying hardware is ordering the read-to-write case on weakly ordered
hardware.

Or, again, am I missing your point?

							Thanx, Paul

> 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
>