Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2088374ybi; Thu, 20 Jun 2019 08:57:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxszBj6eHDmkUf1N6ccd0EsfWheUp2XEUDNRD/qKspqf7CunKKDmaO+gn0C9m45p5qEhUA X-Received: by 2002:a65:638a:: with SMTP id h10mr13940177pgv.64.1561046234367; Thu, 20 Jun 2019 08:57:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561046234; cv=none; d=google.com; s=arc-20160816; b=rNwzqNujVELylgHL1p/SsysWeQnzuPZuaflCPViSas8USuAR0UvHYNGML2nqAH84MP DPvPUvxKtCjf48r17GvINQDSYmF9JKkMCnR4P9yjVv3We2pCTRAIyC73fc5AQidUKtBu qNzEn8A+PfAZYehP+Dbwl4Aq92riRAJhap/bL0cOQntMeoDNEzyy+gxxNgIgK5lZFF/i sBXS2eS59/kcESuyMRCWXT39+bRmkbXdo/dU5Fnp/8XuWBlmsJPHix22xw5LMCzqMwZ9 CRiHWgAeyK8WupuHjKUTzrZM16wvdXG8pp/91fd4x97DQ3BrFZfueT3kvHdy+2i07tlK kHhg== 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:subject:cc:to :from:date; bh=/EjJXdVUj93jUWrotih/bWWkGf38IqLukqDrPYX7cxI=; b=u9Ll3DvkNsXZXyPGFtyi29SDCrlmsP6NnYbxWtZYKCYNRcdtyv6poIRGkfc4bo6zCd vP7f92ecSHHv7UQwHonEm0Cjtp97ggBeWPOxL90sMuG04JoChT9zc3BbOjAs9Fy+eX3g dEjIkQUm0Y2jaF7IRM6MF14afnvrZHzqcolTaN+QJd1oKaPHot8CV60Zz564AIMTZTE7 KkCt90ebIpOBRHkLwh331hrWrgVlcaOQ0/wpCatR8C28XOG+BOAwU/tY0SiXImpl8TR3 i6kQ4WmeJSEMSZAJdjYfdLWgEO/ULg4q4/8Vsjany+kkWOEnF7IwU61/2rHNcaynScvx XnQw== 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 n63si146638pjb.36.2019.06.20.08.56.59; Thu, 20 Jun 2019 08:57:14 -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 S1731733AbfFTPzr (ORCPT + 99 others); Thu, 20 Jun 2019 11:55:47 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:44934 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726551AbfFTPzr (ORCPT ); Thu, 20 Jun 2019 11:55:47 -0400 Received: (qmail 4706 invoked by uid 2102); 20 Jun 2019 11:55:46 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Jun 2019 11:55:46 -0400 Date: Thu, 20 Jun 2019 11:55:46 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: LKMM Maintainers -- Akira Yokosawa , Andrea Parri , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon cc: Kernel development list Subject: [PATCH 2/3] tools: memory-model: Change definition of rcu-fence 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 The rcu-fence relation in the Linux Kernel Memory Model is not well named. It doesn't act like any other fence relation, in that it does not relate events before a fence to events after that fence. All it does is relate certain RCU events to one another (those that are ordered by the RCU Guarantee); this induces an actual strong-fence-like relation linking events preceding the first RCU event to those following the second. This patch renames rcu-fence, now called rcu-order. It adds a new definition of rcu-fence, something which should have been present all along because it is used in the rb relation. And it modifies the fence and strong-fence relations by making them incorporate the new rcu-fence. As a result of this change, there is no longer any need to define full-fence in the section for detecting data races. It can simply be replaced by the updated strong-fence relation. This change should have no effect on the operation of the memory model. Signed-off-by: Alan Stern --- tools/memory-model/linux-kernel.cat | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) Index: usb-devel/tools/memory-model/linux-kernel.cat =================================================================== --- usb-devel.orig/tools/memory-model/linux-kernel.cat +++ usb-devel/tools/memory-model/linux-kernel.cat @@ -124,24 +124,28 @@ let rcu-link = po? ; hb* ; pb* ; prop ; (* * Any sequence containing at least as many grace periods as RCU read-side - * critical sections (joined by rcu-link) acts as a generalized strong fence. + * critical sections (joined by rcu-link) induces order like a generalized + * inter-CPU strong fence. * Likewise for SRCU grace periods and read-side critical sections, provided * the synchronize_srcu() and srcu_read_[un]lock() calls refer to the same * struct srcu_struct location. *) -let rec rcu-fence = rcu-gp | srcu-gp | +let rec rcu-order = rcu-gp | srcu-gp | (rcu-gp ; rcu-link ; rcu-rscsi) | ((srcu-gp ; rcu-link ; srcu-rscsi) & loc) | (rcu-rscsi ; rcu-link ; rcu-gp) | ((srcu-rscsi ; rcu-link ; srcu-gp) & loc) | - (rcu-gp ; rcu-link ; rcu-fence ; rcu-link ; rcu-rscsi) | - ((srcu-gp ; rcu-link ; rcu-fence ; rcu-link ; srcu-rscsi) & loc) | - (rcu-rscsi ; rcu-link ; rcu-fence ; rcu-link ; rcu-gp) | - ((srcu-rscsi ; rcu-link ; rcu-fence ; rcu-link ; srcu-gp) & loc) | - (rcu-fence ; rcu-link ; rcu-fence) + (rcu-gp ; rcu-link ; rcu-order ; rcu-link ; rcu-rscsi) | + ((srcu-gp ; rcu-link ; rcu-order ; rcu-link ; srcu-rscsi) & loc) | + (rcu-rscsi ; rcu-link ; rcu-order ; rcu-link ; rcu-gp) | + ((srcu-rscsi ; rcu-link ; rcu-order ; rcu-link ; srcu-gp) & loc) | + (rcu-order ; rcu-link ; rcu-order) +let rcu-fence = po ; rcu-order ; po? +let fence = fence | rcu-fence +let strong-fence = strong-fence | rcu-fence (* rb orders instructions just as pb does *) -let rb = prop ; po ; rcu-fence ; po? ; hb* ; pb* ; [Marked] +let rb = prop ; rcu-fence ; hb* ; pb* ; [Marked] irreflexive rb as rcu @@ -165,9 +169,8 @@ flag ~empty mixed-accesses as mixed-acce (* Executes-before and visibility *) let xbstar = (hb | pb | rb)* -let full-fence = strong-fence | (po ; rcu-fence ; po?) let vis = cumul-fence* ; rfe? ; [Marked] ; - ((full-fence ; [Marked] ; xbstar) | (xbstar & int)) + ((strong-fence ; [Marked] ; xbstar) | (xbstar & int)) (* Boundaries for lifetimes of plain accesses *) let w-pre-bounded = [Marked] ; (addr | fence)?