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;
Date:   Mon, 26 Nov 2018 14:35:09 -0800
From:   "Paul E. McKenney" <paulmck@linux.ibm.com>
To:     Andrea Parri <andrea.parri@amarulasolutions.com>
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Daniel Lustig <dlustig@nvidia.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Nicholas Piggin <npiggin@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>,
        Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] tools/memory-model: Add SRCU support
Reply-To: paulmck@linux.ibm.com
References: <Pine.LNX.4.44L0.1811151101310.1308-100000@iolanthe.rowland.org>
 <20181119120120.GA5092@andrea>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181119120120.GA5092@andrea>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20181126223509.GM4170@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 19, 2018 at 01:01:20PM +0100, Andrea Parri wrote:
> On Thu, Nov 15, 2018 at 11:19:24AM -0500, Alan Stern wrote:
> > Paul and other LKMM maintainers:
> > 
> > The following series of patches adds support for SRCU to the Linux
> > Kernel Memory Model.  That is, it adds the srcu_read_lock(),
> > srcu_read_unlock(), and synchronize_srcu() primitives to the model.
> > 
> > 	Patch 1/3 does some renaming of the RCU parts of the
> > 	memory model's existing CAT code, to help distinguish them
> > 	from the upcoming SRCU parts.
> > 
> > 	Patch 2/3 refactors the definitions of some RCU relations
> > 	in the CAT code, in a way that the SRCU portions will need.
> > 
> > 	Patch 3/3 actually adds the SRCU support.
> > 
> > This new code requires herd7 version 7.51+4(dev) or later (now 
> > available in the herdtools7 github repository) to run.  Thanks to Luc 
> > for making the necessary changes to support SRCU.
> 
> Thank you Alan, Luc.
> 
> My only suggestion is to integrate changes to explanation.txt (in part.,
> Sect. 22), which the above renaming and refactoring make out-of-date.

Also tools/memory-model/README, but please see below.

> For this version,
> 
> Tested-by: Andrea Parri <andrea.parri@amarulasolutions.com>

Applied to all three, thank you!

							Thanx, Paul

>   Andrea
> 
> 
> > 
> > The code does not check that the index argument passed to 
> > srcu_read_unlock() is the same as the value returned by the 
> > corresponding srcu_read_lock() call.  This is deemed to be a semantic 
> > issue, not directly relevant to the memory model.
> > 
> > Alan

------------------------------------------------------------------------

commit 72f61917f12236514a70017d1ebafb9b8d34a9b6
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date:   Mon Nov 26 14:26:43 2018 -0800

    tools/memory-model: Update README for addition of SRCU
    
    This commit updates the section on LKMM limitations to no longer say
    that SRCU is not modeled, but instead describe how LKMM's modeling of
    SRCU departs from the Linux-kernel implementation.
    
    TL;DR:  There is no known valid use case that cares about the Linux
    kernel's ability to have partially overlapping SRCU read-side critical
    sections.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>

diff --git a/tools/memory-model/README b/tools/memory-model/README
index 0f2c366518c6..9d7d4f23503f 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -221,8 +221,29 @@ The Linux-kernel memory model has the following limitations:
 		additional call_rcu() process to the site of the
 		emulated rcu-barrier().
 
-	e.	Sleepable RCU (SRCU) is not modeled.  It can be
-		emulated, but perhaps not simply.
+	e.	Although sleepable RCU (SRCU) is now modeled, there
+		are some subtle differences between its semantics and
+		those in the Linux kernel.  For example, the kernel
+		might interpret the following sequence as two partially
+		overlapping SRCU read-side critical sections:
+
+			 1  r1 = srcu_read_lock(&my_srcu);
+			 2  do_something_1();
+			 3  r2 = srcu_read_lock(&my_srcu);
+			 4  do_something_2();
+			 5  srcu_read_unlock(&my_srcu, r1);
+			 6  do_something_3();
+			 7  srcu_read_unlock(&my_srcu, r2);
+
+		In contrast, LKMM will interpret this as a nested pair of
+		SRCU read-side critical sections, with the outer critical
+		section spanning lines 1-7 and the inner critical section
+		spanning lines 3-5.
+
+		This difference would be more of a concern had anyone
+		identified a reasonable use case for partially overlapping
+		SRCU read-side critical sections.  For more information,
+		please see: https://paulmck.livejournal.com/40593.html
 
 	f.	Reader-writer locking is not modeled.  It can be
 		emulated in litmus tests using atomic read-modify-write