From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752419AbcI3Nfh (ORCPT ); Fri, 30 Sep 2016 09:35:37 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37513 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbcI3Nf3 (ORCPT ); Fri, 30 Sep 2016 09:35:29 -0400 Date: Fri, 30 Sep 2016 06:35:25 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Will Deacon , linux-kernel@vger.kernel.org, mingo@kernel.org, dhowells@redhat.com, stern@rowland.harvard.edu Subject: Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability Reply-To: paulmck@linux.vnet.ibm.com References: <20160929164353.GX14933@linux.vnet.ibm.com> <20160929171036.GV13862@arm.com> <20160929172322.GZ14933@linux.vnet.ibm.com> <20160929180444.GA22882@linux.vnet.ibm.com> <20160929181015.GB22882@linux.vnet.ibm.com> <20160929184439.GD5016@twins.programming.kicks-ass.net> <20160929191858.GD14933@linux.vnet.ibm.com> <20160930095738.GG5016@twins.programming.kicks-ass.net> <20160930121403.GO14933@linux.vnet.ibm.com> <20160930125113.GY5012@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160930125113.GY5012@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16093013-0012-0000-0000-000010C8042C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005830; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000186; SDB=6.00763086; UDB=6.00363839; IPR=6.00538244; BA=6.00004774; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012830; XFM=3.00000011; UTC=2016-09-30 13:35:26 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16093013-0013-0000-0000-000045ECBD2D Message-Id: <20160930133525.GR14933@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-30_07:,, 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-1609280000 definitions=main-1609300246 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 30, 2016 at 02:51:13PM +0200, Peter Zijlstra wrote: > On Fri, Sep 30, 2016 at 05:14:03AM -0700, Paul E. McKenney wrote: > > PowerPC does not "obscure" stores, so both stores really are there and > > the lwsync really has effect on all CPUs. From what I understand, even > > CPUs that do obscure stores only do so in the case of repeated stores > > by the same CPU to the same variable, and the above litmus test doesn't > > have this. > > > > So all the stores happen, and each CPU's stores are at least locally > > ordered. > > OK, when I'm not sure I ever understood the case where smp_wmb() went > wonky on PPC, sadly I cannot now find the email where you mentioned > that :/ First, a better explanation of your example: PPC PeterZijlstra+o-r+o-r+a-o-SB.litmus { 0:r1=1; 0:r2=2; 0:r3=x; 0:r4=y; 1:r1=1; 1:r2=2; 1:r3=x; 1:r4=y; 2:r3=x; 2:r4=y; } P0 | P1 | P2 ; stw r1,0(r3) | stw r2,0(r3) | lwz r1,0(r4) ; lwsync | lwsync | lwsync ; stw r1,0(r4) | stw r2,0(r4) | lwz r2,0(r3) ; exists (x=2 /\ y=1 /\ 2:r1=1 /\ 2:r2=1) Given that 2:r1=1, and ignoring P1 for the moment, we have simple message passing. If P2 sees P0's store to y, it must also see P0's store to x. So what happens when we include P1? Well, we have constrained the test to the case where P2 sees P0's store to y, so P2's load from x must still see P0's store to x, or some later store to x. Either way, given that P2 sees P0's store to y, it cannot see the initial value of x. In other words, even if P0's store to x is overwritten, it still has effect on the ordering. There are several changes to the litmus test that could require ordering that lwsync does not provide, which I suppose could be considered to introduce wonkiness. ;-) One is the infamous "Z6.3" litmus test that you called out in your earlier email. At least one of the pairs of stores must be separated by sync rather than lwsync. Z6.3's third variable defeats lwsync's local ordering. Thanx, Paul