From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936243AbcHJT7J (ORCPT ); Wed, 10 Aug 2016 15:59:09 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36111 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935655AbcHJSdF (ORCPT ); Wed, 10 Aug 2016 14:33:05 -0400 X-IBM-Helo: d01dlp03.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com Date: Wed, 10 Aug 2016 11:33:04 -0700 From: "Paul E. McKenney" To: Benjamin Herrenschmidt Cc: Manfred Spraul , Michael Ellerman , Andrew Morton , Davidlohr Bueso , Linux Kernel Mailing List , Susi Sonnenschein <1vier1@web.de> Subject: Re: spin_lock implicit/explicit memory barrier Reply-To: paulmck@linux.vnet.ibm.com References: <1470787537.3015.83.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1470787537.3015.83.camel@kernel.crashing.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081018-0040-0000-0000-000001072A96 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005574; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000180; SDB=6.00742807; UDB=6.00349697; IPR=6.00515364; BA=6.00004655; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012302; XFM=3.00000011; UTC=2016-08-10 18:33:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081018-0041-0000-0000-000004E194DB Message-Id: <20160810183304.GK3482@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-10_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608100190 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 10, 2016 at 10:05:37AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > > Hi Benjamin, Hi Michael, > > > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to  > > arch_spin_is_locked()"): > > > > For the ipc/sem code, I would like to replace the spin_is_locked() with  > > a smp_load_acquire(), see: > > > > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/tree/ipc/sem.c#n367 > > > > http://www.ozlabs.org/~akpm/mmots/broken-out/ipc-semc-fix-complex_count-vs-simple-op-race.patch > > > > To my understanding, I must now add a smp_mb(), otherwise it would be  > > broken on PowerPC: > > > > The approach that the memory barrier is added into spin_is_locked()  > > doesn't work because the code doesn't use spin_is_locked(). > > > > Correct? > > Right, otherwise you aren't properly ordered. The current powerpc locks provide > good protection between what's inside vs. what's outside the lock but not vs. > the lock *value* itself, so if, like you do in the sem code, use the lock > value as something that is relevant in term of ordering, you probably need > an explicit full barrier. > > Adding Paul McKenney. To amplify what Ben said... Any CPU holding a given lock will see any previous accesses made under the protection of that lock. A CPU -not- holding the lock can see misordering. As Ben noted, to that non-lock-holding CPU it might appear that a write made under the protection of that lock was made after the lock was released. Similarly, to that CPU it might appear that a load done under the protection of that lock completed before the lock was acquired. Finally, a CPU not holding the lock might see a store by one CPU holding the lock as happening after a load (from some other variable) by the next CPU holding that lock. Thanx, Paul