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

[Manfred Spraul]

On 09/01/2016 06:41 PM, 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.
> 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.
CPU1:
x=1; /* without WRITE_ONCE */
LOCK(l);
UNLOCK(l);
<do_semop>
smp_store_release(x,0)


CPU2;
LOCK(l)
if (smp_load_acquire(x)==1) goto slow_path
<do_semop>
UNLOCK(l)

Ordering is enforced because both CPUs access the same lock.

x=1 can't be reordered past the UNLOCK(l), I don't see that further 
guarantees are necessary.

Correct?

--
    Manfred