linux-kernel - Re: [PATCH 18/28] ARC: add smp barriers around atomics per memory-barrriers.txt

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150610105323.GF3644@twins.programming.kicks-ass.net>
Date:	Wed, 10 Jun 2015 12:53:23 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 18/28] ARC: add smp barriers around atomics per
 memory-barrriers.txt

On Wed, Jun 10, 2015 at 09:17:16AM +0000, Vineet Gupta wrote:
> >> --- a/arch/arc/include/asm/spinlock.h
> >> +++ b/arch/arc/include/asm/spinlock.h
> >> @@ -22,24 +22,32 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> >>  {
> >>  	unsigned int tmp = __ARCH_SPIN_LOCK_LOCKED__;
> >>  
> >> +	smp_mb();
> >> +
> >>  	__asm__ __volatile__(
> >>  	"1:	ex  %0, [%1]		\n"
> >>  	"	breq  %0, %2, 1b	\n"
> >>  	: "+&r" (tmp)
> >>  	: "r"(&(lock->slock)), "ir"(__ARCH_SPIN_LOCK_LOCKED__)
> >>  	: "memory");
> >> +
> >> +	smp_mb();
> >>  }

> > Both these are only required to provide an ACQUIRE barrier, if all you
> > have is smp_mb(), the second is sufficient.
> 
> Essentially ARCv2 is weakly ordered with explicit ordering provided by DMB
> instructions with semantics load/load, store/store, all/all.
> 
> I wanted to clarify a couple of things
> (1) ACQUIRE barrier implies store/{store,load} while RELEASE implies
> {load,store}/store and given what DMB provides for ARCv2, smp_mb() is the only fit ?

Please see Documentation/memory-barriers.txt, but a quick recap:

 - ACQUIRE: both loads and stores before to the barrier are allowed to
   be observed after it.  Neither loads nor stores after the barrier are
   allowed to be observed before it.

 - RELEASE: both loads and stores before it must be observed before the
   barrier. However, any load or store after it may be observed before
   it.

Therefore:

 X = Y = 0;

	[S] X = 1
	    ACQUIRE

	    RELEASE
	[S] Y = 1

is in fact fully unordered, because both stores are allowed to cross in,
and could cross one another on the inside, like:

	    ACQUIRE
	[S] Y = 1
	[S] X = 1
	    RELEASE

> (2) Do we need smp_mb() on both sides of spin lock/unlock - doesn't ACQUIRE imply
> we have a smp_mb() after lock but before any subsequent critical section - so the
> top hunk is not necessarily needed. Similarly RELEASE requires a smp_mb() before
> the memory operation for lock, but not after.

You do not need an smp_mb() on both sides, as you say, after lock and
before unlock is sufficient. The main point being that things can not
escape out of the critical section. Its fine for them to leak in.
--
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/