Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1217125imm; Fri, 22 Jun 2018 12:24:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIOZFbzdsbjc/pmtPWyF01fCeL/WJ6cKixMUHBLg4IRl41eqm3DNn3BEbT5MxhhC4lULmhh X-Received: by 2002:a17:902:6b84:: with SMTP id p4-v6mr2955668plk.272.1529695451649; Fri, 22 Jun 2018 12:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529695451; cv=none; d=google.com; s=arc-20160816; b=kvzIZvMVUHVPfnv0WcN7OZDmXPn52HEadg29gxsvM5YWPyrVcoJkWkQtGC4A0dPvMp fG9vLuBB0wJwlDw/IJmwaaE4PkMO6Ysm3XMa744YehRb3wKWPN1X2UjxTUnCBjy/byEz r8VP9UtsLRVFUeabh04KHQsfLPsilhWXHXLQZm8LTUMcm9U+p3RpKywYR0SHP/ZNV1/+ Bh9dlx3+qcHIowMwgaguGpBr0DLCaxkfABHYpYSXASvrrkTYkgPZuF62xM3b+ShH5fLM UrKxmqF+eFFGHtvnZv3UZ3yASU4kzMBvMuhw+zqkedo8HG5DxW4+x1+JX9AM9ujTp0VN tI2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=lqpbOdbfHrqxJxoSm1cUyo08DcK5lj/QeGpBzVcZIDk=; b=uEjH5FZhHTqCEFOsWDexCSY273Vosd4RfU5GMaU6a7zUhTy4iG+yq117IdAf6gl1oT +KCEDAm0UcnusjxoDAuGm0uivpjAxdtkUp40dXZ5p8u/iQwcZF4OmvAgoawL9pCKJcK3 2SEtusAedsa1AWa87GR7HMo0AboEagb4WQSrew16BF5fLDcU88LPLdWhL9OBp5BrfLKn g7PDEEh8Ezq4eK/QdR9A+WlNCZvAI0fjhVTGQLdXXQpmIzOnJcGOnJXuDsyTDTphSlF2 6qUedBn6YJctt6b2nLPB/o3VeKsl/pJXNMeO2jfqn1MtdpTuvCIoEesPISBJYlKJQB72 K0nQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2-v6si6436410pgt.611.2018.06.22.12.23.57; Fri, 22 Jun 2018 12:24:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934407AbeFVTXI (ORCPT + 99 others); Fri, 22 Jun 2018 15:23:08 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:36584 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S934096AbeFVTXH (ORCPT ); Fri, 22 Jun 2018 15:23:07 -0400 Received: (qmail 5320 invoked by uid 2102); 22 Jun 2018 15:23:06 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Jun 2018 15:23:06 -0400 Date: Fri, 22 Jun 2018 15:23:06 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrea Parri cc: LKMM Maintainers -- Akira Yokosawa , Boqun Feng , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon , Kernel development list Subject: Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks In-Reply-To: <20180622090651.GB6933@andrea> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2018, Andrea Parri wrote: > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by release-acquire chains and by > > locking. In other words, given the following code: > > > > WRITE_ONCE(x, 1); > > spin_unlock(&s): > > spin_lock(&s); > > WRITE_ONCE(y, 1); > > > > or the following: > > > > smp_store_release(&x, 1); > > r1 = smp_load_acquire(&x); // r1 = 1 > > WRITE_ONCE(y, 1); > > > > the stores to x and y should be propagated in order to all other CPUs, > > even though those other CPUs might not access the lock s or be part of > > the release-acquire chain. In terms of the memory model, this means > > that rel-rf-acq-po should be part of the cumul-fence relation. > > > > All the architectures supported by the Linux kernel (including RISC-V) > > do behave this way, albeit for varying reasons. Therefore this patch > > changes the model in accordance with the developers' wishes. > > > > Signed-off-by: Alan Stern > > This patch changes the "Result" for ISA2+pooncelock+pooncelock+pombonce, > so it should update the corresponding comment/README. Thanks for noticing this. The next version of this patch will update the comment. The README seems to be adequate as it is now, since it doesn't specify the result of the litmus test. Alan