From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934227AbcHJWX3 (ORCPT ); Wed, 10 Aug 2016 18:23:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:58956 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933552AbcHJWX1 (ORCPT ); Wed, 10 Aug 2016 18:23:27 -0400 Date: Wed, 10 Aug 2016 15:23:16 -0700 From: Davidlohr Bueso To: "Paul E. McKenney" Cc: Manfred Spraul , Benjamin Herrenschmidt , Michael Ellerman , Andrew Morton , Linux Kernel Mailing List , Susanne Spraul <1vier1@web.de>, Peter Zijlstra , parri.andrea@gmail.com Subject: Re: spin_lock implicit/explicit memory barrier Message-ID: <20160810222316.GA22336@linux-80c1.suse> References: <1470787537.3015.83.camel@kernel.crashing.org> <4bd34301-0c63-66ae-71b1-6fd68c9fecdd@colorfullife.com> <20160810205202.GL3482@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160810205202.GL3482@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, but as mentioned, spin_unlock_wait for tickets are now at least an acquire (ppc is stronger), 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? Thanks, Davidlohr