From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932636AbcHKAAv (ORCPT <rfc822;w@1wt.eu>);
	Wed, 10 Aug 2016 20:00:51 -0400
Received: from gate.crashing.org ([63.228.1.57]:43404 "EHLO gate.crashing.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750882AbcHKAAs (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 10 Aug 2016 20:00:48 -0400
Message-ID: <1470873598.3015.118.camel@kernel.crashing.org>
Subject: Re: spin_lock implicit/explicit memory barrier
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Davidlohr Bueso <dave@stgolabs.net>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Manfred Spraul <manfred@colorfullife.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Susanne Spraul <1vier1@web.de>, Peter Zijlstra <peterz@infradead.org>,
        parri.andrea@gmail.com
Date: Thu, 11 Aug 2016 09:59:58 +1000
In-Reply-To: <20160810222316.GA22336@linux-80c1.suse>
References: <abcae6c7-6269-94e0-3e66-b7d07fbe10dc@colorfullife.com>
	 <1470787537.3015.83.camel@kernel.crashing.org>
	 <4bd34301-0c63-66ae-71b1-6fd68c9fecdd@colorfullife.com>
	 <20160810205202.GL3482@linux.vnet.ibm.com>
	 <20160810222316.GA22336@linux-80c1.suse>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.4 (3.20.4-1.fc24) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2016-08-10 at 15:23 -0700, Davidlohr Bueso wrote:
> On Wed, 10 Aug 2016, Paul E. McKenney wrote:
> 
> > 
> > On Wed, Aug 10, 2016 at 08:21:22PM +0200, Manfred Spraul wrote:
>                                                               4)
> > > spin_unlock_wait() and spin_unlock() pair
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n291
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n409
> > > The data from the simple op must be observed by the following
> > > complex op. Right now, there is still an smp_rmb() in line 300: The
> > > control barrier from the loop inside spin_unlock_wait() is upgraded
> > > to an acquire barrier by an additional smp_rmb(). Is this smp_rmb()
> > > required? If I understand commit 2c6100227116 ("locking/qspinlock:
> > > Fix spin_unlock_wait() some more") right, with this commit qspinlock
> > > handle this case without the smp_rmb(). What I don't know if powerpc
> > > is using qspinlock already, or if powerpc works without the
> > > smp_rmb(). -- Manfred|
> 
> > No, ppc doesn't use qspinlocks, 

 ... yet. There are patches pending to add support for them

> but as mentioned, spin_unlock_wait for
> > tickets are now at least an acquire (ppc is stronger), 

The unlock path for qspinlock for us will be a release.

> which match that
> unlock store-release you are concerned about, this is as of 726328d92a4
> (locking/spinlock, arch: Update and fix spin_unlock_wait() implementations).
> 
> This is exactly what you are doing by upgrading the ctrl dependency to 
> the acquire barrier in http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n291
> and therefore we don't need it explicitly -- it also makes the comment
> wrt spin_unlock_wait obsolete. Or am I'm misunderstanding you?

Ben.