Re: [PATCH 8/7] net/netfilter/nf_conntrack_core: Remove another memory barrier

[Boqun Feng <boqun.feng@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Hi Manfred,

On Thu, Sep 01, 2016 at 06:41:26PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 04:30:39PM +0100, Will Deacon wrote:
> > On Thu, Sep 01, 2016 at 05:27:52PM +0200, Manfred Spraul wrote:
> > > Since spin_unlock_wait() is defined as equivalent to spin_lock();
> > > spin_unlock(), the memory barrier before spin_unlock_wait() is
> > > also not required.
> 

As Peter said below, ACQUIRE+RELEASE is not a barrier.

What we rely here is that spin_unlock_wait() could pair with another
LOCK or UNLOCK(as spin_unlock_wait() acts as spin_lock();
spin_unlock()). And once paired, we could have the necessary order
guarantee between the code preceding or following unlock_wait() and the
code in the lock critical sections.

Regards,
Boqun

> Note that ACQUIRE+RELEASE isn't a barrier.
> 
> Both are semi-permeable and things can cross in the middle, like:
> 
> 
> 	x = 1;
> 	LOCK
> 	UNLOCK
> 	r = y;
> 
> can (validly) get re-ordered like:
> 
> 	LOCK
> 	r = y;
> 	x = 1;
> 	UNLOCK
> 
> So if you want things ordered, as I think you do, I think the smp_mb()
> is still needed.
> 
> RELEASE + ACQUIRE otoh, that is a load-store barrier (but not
> transitive).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]