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, 27 May 2016 11:05:48 +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 Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote: > On 5/26/2016 10:19 AM, Peter Zijlstra wrote: > >--- a/arch/tile/lib/spinlock_32.c > >+++ b/arch/tile/lib/spinlock_32.c > >@@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock > > if (next == curr) > > return; > >+ smp_rmb(); > >+ > > /* Wait until the current locker has released the lock. */ > > do { > > delay_backoff(iterations++); > > } while (READ_ONCE(lock->current_ticket) == curr); > >+ > >+ smp_acquire__after_ctrl_dep(); > > } > > EXPORT_SYMBOL(arch_spin_unlock_wait); > >--- a/arch/tile/lib/spinlock_64.c > >+++ b/arch/tile/lib/spinlock_64.c > >@@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock > > if (arch_spin_next(val) == curr) > > return; > >+ smp_rmb(); > >+ > > /* Wait until the current locker has released the lock. */ > > do { > > delay_backoff(iterations++); > > } while (arch_spin_current(READ_ONCE(lock->lock)) == curr); > >+ > >+ smp_acquire__after_ctrl_dep(); > > } > > EXPORT_SYMBOL(arch_spin_unlock_wait); > > The smp_rmb() are unnecessary for tile. We READ_ONCE next/curr from the > lock and compare them, so we know the load(s) are complete. There's no > microarchitectural speculation going on so that's that. Then we READ_ONCE > the next load on the lock from within the wait loop, so our load/load > ordering is guaranteed. 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().
Powered by blists - more mailing lists