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]

Date:	Thu, 14 Jan 2016 13:01:05 -0800
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	<paulmck@...ux.vnet.ibm.com>
CC:	Will Deacon <will.deacon@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	<linux-kernel@...r.kernel.org>, "Arnd Bergmann" <arnd@...db.de>,
	<linux-arch@...r.kernel.org>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	<virtualization@...ts.linux-foundation.org>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Joe Perches <joe@...ches.com>,
	David Miller <davem@...emloft.net>,
	<linux-ia64@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	<linux-s390@...r.kernel.org>, <sparclinux@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-metag@...r.kernel.org>, <linux-mips@...ux-mips.org>,
	<x86@...nel.org>, <user-mode-linux-devel@...ts.sourceforge.net>,
	<adi-buildroot-devel@...ts.sourceforge.net>,
	<linux-sh@...r.kernel.org>, <linux-xtensa@...ux-xtensa.org>,
	<xen-devel@...ts.xenproject.org>,
	"Ralf Baechle" <ralf@...ux-mips.org>,
	Ingo Molnar <mingo@...nel.org>, <ddaney.cavm@...il.com>,
	<james.hogan@...tec.com>, Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h

I need some time to understand your test examples. However,

On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>
>
> The WRC+addr+addr is OK because data dependencies are not required to be
> transitive, in other words, they are not required to flow from one CPU to
> another without the help of an explicit memory barrier.

I don't see any reliable way to fit WRC+addr+addr into "DATA DEPENDENCY 
BARRIERS" section recommendation to have data dependency barrier between 
read of a shared pointer/index and read the shared data based on that 
pointer. If you have this two reads, it doesn't matter the rest of 
scenario, you should put the dependency barrier in code anyway. If you 
don't do it in WRC+addr+addr scenario then after years it can be easily 
changed to different scenario which fits some of scenario in "DATA 
DEPENDENCY BARRIERS" section and fails.

>    Transitivity is

Peter Zijlstra recently wrote: "In particular we're very much all 
'confused' about the various notions of transitivity". I am confused 
too, so - please use some more simple way to explain your words. Sorry, 
but we need a common ground first.

- Leonid.