linux-kernel - Re: Behaviour of smp_mb__{before,after}

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150120093443.GA11596@twins.programming.kicks-ass.net>
Date:	Tue, 20 Jan 2015 10:34:43 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Will Deacon <will.deacon@....com>
Cc:	paulmck@...ux.vnet.ibm.com, torvalds@...ux-foundation.org,
	oleg@...hat.com, benh@...nel.crashing.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Behaviour of smp_mb__{before,after}_spin* and acquire/release

On Tue, Jan 13, 2015 at 04:33:54PM +0000, Will Deacon wrote:
> Hi Paul,
> 
> I started dusting off a series I've been working to implement a relaxed
> atomic API in Linux (i.e. things like atomic_read(v, ACQUIRE)) but I'm
> having trouble making sense of the ordering semantics we have in mainline
> today:

>   2. Does smp_mb__after_unlock_lock order smp_store_release against
>      smp_load_acquire? Again, Documentation/memory-barriers.txt puts
>      these operations into the RELEASE and ACQUIRE classes respectively,
>      but since smp_mb__after_unlock_lock is a NOP everywhere other than
>      PowerPC, I don't think this is enforced by the current code. 

Yeah, wasn't Paul going to talk to Ben about that? PPC is the only arch
that has the weak ACQUIRE/RELEASE for its spinlocks.

>      Most
>      architectures follow the pattern used by asm-generic/barrier.h:
> 
>        release: smp_mb(); STORE
>        acquire: LOAD; smp_mb();
> 
>      which doesn't provide any release -> acquire ordering afaict.

Only when combined on the same address, if the LOAD observes the result
of the STORE we can guarantee the rest of the ordering. And if you
build a locking primitive with them (or circular lists or whatnot) you
have that extra condition.

But yes, I see your argument that this implementation is weak like the
PPC.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/