From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752589AbdK2TdK (ORCPT ); Wed, 29 Nov 2017 14:33:10 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35390 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752014AbdK2TdJ (ORCPT ); Wed, 29 Nov 2017 14:33:09 -0500 Date: Wed, 29 Nov 2017 11:33:05 -0800 From: "Paul E. McKenney" To: Daniel Lustig Cc: Alan Stern , Andrea Parri , Luc Maranget , Jade Alglave , Boqun Feng , Nicholas Piggin , Peter Zijlstra , Will Deacon , David Howells , Palmer Dabbelt , Kernel development list Subject: Re: Unlock-lock questions and the Linux Kernel Memory Model Reply-To: paulmck@linux.vnet.ibm.com References: <17506ed0-1ce8-791d-7cf1-c40426015a99@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17506ed0-1ce8-791d-7cf1-c40426015a99@nvidia.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17112919-0036-0000-0000-00000293C194 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008123; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000242; SDB=6.00953033; UDB=6.00481506; IPR=6.00733112; BA=6.00005721; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018254; XFM=3.00000015; UTC=2017-11-29 19:33:07 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112919-0037-0000-0000-000042865412 Message-Id: <20171129193305.GG3624@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-29_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290252 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote: > On 11/27/2017 1:16 PM, Alan Stern wrote: > > This is essentially a repeat of an email I sent out before the > > Thanksgiving holiday, the assumption being that lack of any responses > > was caused by the holiday break. (And this time the message is CC'ed > > to LKML, so there will be a public record of it.) > > > > A few people have said they believe the Linux Kernel Memory Model > > should make unlock followed by lock (of the same variable) act as a > > write memory barrier. In other words, they want the memory model to > > forbid the following litmus test: > > > > > > > I (and others!) would like to know people's opinions on these matters. > > > > Alan Stern > > While we're here, let me ask about another test which isn't directly > about unlock/lock but which is still somewhat related to this > discussion: > > "MP+wmb+xchg-acq" (or some such) If you make the above be "C MP+wmb+xchg-acq", then this is currently allowed by the current version of the Linux kernel memory model. Also by the hardware model, interestingly enough. Thanx, Paul > {} > > P0(int *x, int *y) > { > WRITE_ONCE(*x, 1); > smp_wmb(); > WRITE_ONCE(*y, 1); > } > > P1(int *x, int *y) > { > r1 = atomic_xchg_relaxed(y, 2); > r2 = smp_load_acquire(y); > r3 = READ_ONCE(*x); > } > > exists (1:r1=1 /\ 1:r2=2 /\ 1:r3=0) > > C/C++ would call the atomic_xchg_relaxed part of a release sequence > and hence would forbid this outcome. > > x86 and Power would forbid this. ARM forbids this via a special-case > rule in the memory model, ordering atomics with later load-acquires. > > RISC-V, however, wouldn't forbid this by default using RCpc or RCsc > atomics for smp_load_acquire(). It's an "fri; rfi" type of pattern, > because xchg doesn't have an inherent internal data dependency. > > If the Linux memory model is going to forbid this outcome, then > RISC-V would either need to use fences instead, or maybe we'd need to > add a special rule to our memory model similarly. This is one detail > where RISC-V is still actively deciding what to do. > > Have you all thought about this test before? Any idea which way you > are leaning regarding the outcome above? > > Thanks, > Dan >