linux-kernel - Re: [RFC][PATCH] mips: Fix arch_spin

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]

Date:	Thu, 28 Jan 2016 09:11:19 +0800
From:	Boqun Feng <boqun.feng@...il.com>
To:	"Maciej W. Rozycki" <macro@...tec.com>
Cc:	Will Deacon <will.deacon@....com>,
	David Daney <ddaney@...iumnetworks.com>,
	Måns Rullgård <mans@...sr.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	linux-kernel@...r.kernel.org,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

Hi Maciej,

On Wed, Jan 27, 2016 at 12:41:29PM +0000, Maciej W. Rozycki wrote:
> On Wed, 27 Jan 2016, Will Deacon wrote:
> 
> > >  Overall I think it should be safe after all to use SYNC_RELEASE and other 
> > > modern lightweight barriers uncondtionally under the assumption that 
> > > architecture was meant to remain backward compatible.  Even though it 
> > > might be possible someone would implement unusual semantics for the then 
> > > undefined `stype' values, I highly doubt it as it would be extra effort 
> > > and hardware logic space for no gain.  We could try and reach architecture 
> > > overseers to double-check whether the `stype' encodings, somewhat 
> > > irregularly distributed, were indeed defined in a manner so as not to 
> > > clash with values implementers chose to use before rev. 2.61 of the 
> > > architecture specification.
> > 
> > Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> > SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)?
> 
>  By my reading of architecture specifications it does.  Specifically 
> SYNC_RELEASE (18) applies to older loads and stores, and newer stores, and 
> SYNC_ACQUIRE (17) applies to older loads, and newer loads and stores.  So 
> the two combined ought to be the equivalent to SYNC_MB (16), which applies 
> to both older and newer loads and stores.  Of course care has to be taken 

Hmm.. so the following reordering couldn't happen?

Program order:

	LOAD A
	SYNC_RELEASE
	STORE B
	LOAD C
	SYNC_ACQUIRE
	LOAD D

First becomes:

	LOAD C <------------ SYNC_RELEASE doesn't order newer loads.
	LOAD A
	SYNC_RELEASE
	STORE B
	SYNC_ACQUIRE
	LOAD D

And then becomes:

	LOAD C
	<SYNC_ACQUIRE> <---- SYNC_ACQUIRE still affect those loads.
	LOAD D <------------ SYNC_RELEASE doesn't order newer loads.
	LOAD A
	SYNC_RELEASE
	STORE B
	SYNC_ACQUIRE

<SYNC_ACQUIRE> here doesn't mean that SYNC instructions can be
reordered, it here means that the reordering doesn't break
SYNC_ACQUIRE's guarantee.

I ask this because some architectures(e.g. PPC) allows this kind of
reordering. Please see "ACQUIRING FUNCTIONS" in memory-barriers.txt for
more information. Thank you ;-)

Regards,
Boqun

> about what happens between SYNC_RELEASE and SYNC_ACQUIRE.  This is still 
> more lightweight than classic SYNC (0).  See the architecture documents, 
> e.g. the MIPS32 one[1] for details.
> 
> References:
> 
> [1] "MIPS Architecture For Programmers, Volume II-A: The MIPS32 
>     Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
>     Revision 5.04, December 11, 2013, Table 4.7 "Encodings of the 
>     Bits[10:6] of the SYNC instruction; the SType Field", p. 305
> 
>  HTH,
> 
>   Maciej
> 

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)