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
| ||
|
Date: Fri, 19 Aug 2016 16:01:06 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Boqun Feng <boqun.feng@...il.com> Cc: Davidlohr Bueso <dave@...olabs.net>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Manfred Spraul <manfred@...orfullife.com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Michael Ellerman <mpe@...erman.id.au>, Andrew Morton <akpm@...ux-foundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Susanne Spraul <1vier1@....de>, parri.andrea@...il.com Subject: Re: spin_lock implicit/explicit memory barrier On Fri, Aug 12, 2016 at 10:59:46AM +0800, Boqun Feng wrote: > But if an arch implements its spin_lock() with a full barrier, even > though the atomic is implemented by ll/sc, the STORE part of which can't > be reordered with memory operations in the critcal sections. I think > maybe that's the case for alpha(and also for ARM32). Correct, Alpha only has a full fence and uses that after the ll/sc to provide acquire semantics, ARM has other barriers but too uses a full barrier here.
Powered by blists - more mailing lists