Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp781719imm; Thu, 5 Jul 2018 08:47:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdaDhixZFSXgy9hE9Ocik0vcUtrYYOrDqy7r1nV155gw/qmppM5qpA+5s8OolBfmWomb23G X-Received: by 2002:a65:410d:: with SMTP id w13-v6mr6056592pgp.414.1530805626745; Thu, 05 Jul 2018 08:47:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530805626; cv=none; d=google.com; s=arc-20160816; b=g6lb8gfDonVtKAeNB1QePXSUHoISbRaoxkBKxgBoLQvvshH5K/xO0MqQsOs3Sf030V 4gZj6bEeDYfuk25aBORA/zf55tgSqs2pQgg0BK2R40+TGjJOv+mznM/cNL/OqhsoiOXj +06IHTk7Slj+cCljWM0dXM20DVZChCSjk2PvZobDM+a+bq/YZqSqKhDXf8nKugz+c0mN dAjHneP+hGpcjKVI5ilYatRBbsZn0gTCpSUV6uFAImOrtmDKM127JVFb61JUMqRZ2mbA UTrrIRN+/4WaPeDYoe+HfW0JNMLs8iPDtWXUngqgLdKFuP9MFoRrbHWk0FgEbnpU0icO AQlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=HSbKabayU2Lc8OYhEi9Kg2O54AXjK9P2tCP19DjCVm4=; b=QGDs9XIsmM44suppxf+KzHbOYmOlABqLy92IBP3uoMYxdO9xp4L6c5ZeOMtEGaKcPf GG2xXiJUL3Zo4dFD2guf+blLBZDJ332Z9sm+vGUMvKWnIBF2+UTZjOwiZDHbb1W/Pmd0 GhSahOqIofM+FGU7RypMEe66iz6AFva0623XdZO1odGGwSVaFANML/BM11Huf+x9764Q jBJhKLtp48GYLCqlRNKXqyKhgRSyTiU3N7XTyPEEHLJtAcVIcgOvo18/8Ce+ORkKrn7C MQElnQ+nXMzPfi7QsoRoJmoKfqccTczPxBlIF9UmGkJ2XlcKSGAerSwGlujouG4IKhQc UEBQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o9-v6si6091584plk.434.2018.07.05.08.46.47; Thu, 05 Jul 2018 08:47:06 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753961AbeGEPon (ORCPT + 99 others); Thu, 5 Jul 2018 11:44:43 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:17734 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753929AbeGEPol (ORCPT ); Thu, 5 Jul 2018 11:44:41 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1, AES128-SHA) id ; Thu, 05 Jul 2018 08:44:37 -0700 Received: from HQMAIL105.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Thu, 05 Jul 2018 08:44:40 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Thu, 05 Jul 2018 08:44:40 -0700 Received: from [10.2.171.197] (10.2.171.197) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Jul 2018 15:44:40 +0000 Subject: Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks To: , Alan Stern CC: Will Deacon , Andrea Parri , LKMM Maintainers -- Akira Yokosawa , Boqun Feng , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Peter Zijlstra , Kernel development list References: <20180704121103.GB26941@arm.com> <20180705153140.GO3593@linux.vnet.ibm.com> From: Daniel Lustig Message-ID: Date: Thu, 5 Jul 2018 08:44:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180705153140.GO3593@linux.vnet.ibm.com> X-Originating-IP: [10.2.171.197] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL105.nvidia.com (172.20.187.12) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/5/2018 8:31 AM, Paul E. McKenney wrote: > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote: >> At any rate, it looks like instead of strengthening the relation, I >> should write a patch that removes it entirely. I also will add new, >> stronger relations for use with locking, essentially making spin_lock >> and spin_unlock be RCsc. > > Only in the presence of smp_mb__after_unlock_lock() or > smp_mb__after_spinlock(), correct? Or am I confused about RCsc? > > Thanx, Paul > In terms of naming...is what you're asking for really RCsc? To me, that would imply that even stores in the first critical section would need to be ordered before loads in the second critical section. Meaning that even x86 would need an mfence in either lock() or unlock()? If you're only looking for R->R, R->W, and W->W ordering between critical sections, is it better to find a new unique name for this? "RCtso" possibly, or something to that effect? Dan