linux-kernel - Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock

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] [day] [month] [year] [list]

Message-ID: <20160530092520.GQ3192@twins.programming.kicks-ass.net>
Date:	Mon, 30 May 2016 11:25:20 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Chris Metcalf <cmetcalf@...lanox.com>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	manfred@...orfullife.com, dave@...olabs.net,
	paulmck@...ux.vnet.ibm.com, will.deacon@....com,
	boqun.feng@...il.com, Waiman.Long@....com, tj@...nel.org,
	pablo@...filter.org, kaber@...sh.net, davem@...emloft.net,
	oleg@...hat.com, netfilter-devel@...r.kernel.org,
	sasha.levin@...cle.com, hofrat@...dl.org, rth@...ddle.net,
	vgupta@...opsys.com, linux@...linux.org.uk, realmz6@...il.com,
	rkuo@...eaurora.org, tony.luck@...el.com, james.hogan@...tec.com,
	ralf@...ux-mips.org, dhowells@...hat.com, jejb@...isc-linux.org,
	mpe@...erman.id.au, schwidefsky@...ibm.com,
	ysato@...rs.sourceforge.jp, chris@...kel.net
Subject: Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On Fri, May 27, 2016 at 03:34:13PM -0400, Chris Metcalf wrote:

> >Does TILE never speculate reads? Because in that case the control
> >dependency already provides a full load->load,store barrier and you'd
> >want smp_acquire__after_ctrl_dep() to be a barrier() instead of
> >smp_rmb().
> 
> Yes, that's a good point.  I didn't look at the definition of smp_acquire__after_ctrl_dep(),
> but it certainly sounds like that's exactly a compiler barrier for tile.  There is no load
> speculation performed.  The only out-of-order stuff that happens is in the memory
> subsystem: stores will become visible in arbitrary order, and loads will arrive in
> arbitrary order, but as soon as the result of a load is used in any other kind of
> instruction, the instruction issue will halt until the pending load(s) for the instruction
> operands are available.

OK; for now I'll just put in barrier() and a big comment, I'll look at
making smp_acquire__after_ctrl_dep() a proper (per arch) barrier later.
There's a little header head-ache involved.