Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp165930imu; Wed, 12 Dec 2018 14:15:34 -0800 (PST) X-Google-Smtp-Source: AFSGD/UrWBB0JZ1g0EDWz58UUemckpRsbQjfX1kix+fIL0Vg4Exn+ck4CQNGBYucjWXjCDFRgqyo X-Received: by 2002:a63:cd11:: with SMTP id i17mr689510pgg.345.1544652934430; Wed, 12 Dec 2018 14:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544652934; cv=none; d=google.com; s=arc-20160816; b=sbv04WVHanDGjaRUXitThadtr38lz9GnGCC6kD7yV1ky9WD0xl/5fCTsCzjge+WB2f c/uD6CNJptfsW2nsxsMHtw79x4DJA5yOP2qO12yDSj03t849/zSwOUPZqjRxHWMF4MNB DSdrOGz4iqXgUi8OO2y7xUVUkeIHHqSDQkxERG2JKJfIpI+qB+wa6hRsZeh4yLE4LJrd ZDeouN6vRtiZk6fCPMBe8vB9xKXas2tl7KutmEEH1GWjnDusdaf8P48nLlWUOB6JNg1H koKQWIeaXBnI4IjGMtI6WONXdFsHhIrAb9Zex3P9172gn4AKKklB0DSUrp8CnO6nnBFI ybuA== 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; bh=dO0c7TAtzDAV5OdnKc/L7nM8CSpV90dIj+QZhNl4mf8=; b=pA1VlzO61S0hxQwEg1KBKsRbHwE+kSFa/cUMTQkhXoHLjXtMiYUMKzKLdQ7WbcYDtq mguF+qw8/VQcagepZgqc91QCyv/Udx+h/8WiOM0tibDexIxjdEBanL2Fxyf9By6SdGj+ WWX+pHpgsQ8jgvOvJIGJkkAIT8436r2nafnWT/9bXwhTfe5+H/ezanyj4MpxoypuWbuA z3BU6t2G6zdcn9KN9qZyjMrlVjvFxVP7L9pDyzDBDXGQU6jXEAynmmlW01/ypGd54MwL CUu6xrL/DoitS2YbQmXZz13RghzlwWq+KjekBwfkoxLedmmB7lzhvjD706snWC42TmRl w9Hg== 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 v6si2472pfj.167.2018.12.12.14.15.19; Wed, 12 Dec 2018 14:15:34 -0800 (PST) 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 S1728450AbeLLWMT (ORCPT + 99 others); Wed, 12 Dec 2018 17:12:19 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:56054 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728376AbeLLWMT (ORCPT ); Wed, 12 Dec 2018 17:12:19 -0500 Received: (qmail 6510 invoked by uid 2102); 12 Dec 2018 17:12:18 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Dec 2018 17:12:18 -0500 Date: Wed, 12 Dec 2018 17:12:18 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Paul E. McKenney" cc: David Goldblatt , , Florian Weimer , , , , , , , , , , , , , , Subject: Re: [PATCH] Linux: Implement membarrier function In-Reply-To: <20181212215245.GC4170@linux.ibm.com> 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 Wed, 12 Dec 2018, Paul E. McKenney wrote: > > > I believe that this ordering forbids the cycle: > > > > > > Wa=1 > membs -> [m01] -> Rc=0 -> Wc=2 -> rcu_read_unlock() -> > > > return from synchronize_rcu() -> Ra > > > > > > Does this make sense, or am I missing something? > > > > It's hard to tell. What you have written here isn't justified by the > > litmus test source code, since the position of m01 in P1's program > > order is undetermined. How do you justify m01 -> Rc, for example? > > ... justifies Rc=0 following [m01]. > > > Write it this way instead, using the relations defined in the > > sys_membarrier patch for linux-kernel.cat: > > > > memb ->memb-gp memb ->rcu-link Rc ->memb-rscsi Rc ->rcu-link > > > > rcu_read_unlock ->rcu-rscsi rcu_read_lock ->rcu-link > > > > synchronize_rcu ->rcu-gp synchronize_rcu ->rcu-link memb > > > > Recall that: > > > > memb-gp is the identity relation on sys_membarrier events, > > > > rcu-link includes (po? ; fre ; po), > > > > memb-rscsi is the identity relation on all events, > > > > rcu-rscsi links unlocks to their corresponding locks, and > > > > rcu-gp is the identity relation on synchronize_rcu events. > > > > These facts justify the cycle above. > > > > Leaving off the final rcu-link step, the sequence matches the > > definition of rcu-fence (the relations are memb-gp, memb-rscsi, > > rcu-rscsi, rcu-gp with rcu-links in between). Therefore the cycle is > > forbidden. > > Understood, but that would be using the model to check the model. ;-) Well, what are you trying to accomplish? Do you want to find an argument similar to the one I posted for the 6-CPU test to show that this test should be forbidden? Alan