From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
mingo@kernel.org
Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com,
will.deacon@arm.com, peterz@infradead.org, boqun.feng@gmail.com,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com,
"Paul E . McKenney" <paulmck@linux.ibm.com>
Subject: [PATCH memory-model 1/7] tools/memory-model: Rename some RCU relations
Date: Wed, 13 Feb 2019 09:37:37 -0800 [thread overview]
Message-ID: <20190213173743.26682-1-paulmck@linux.ibm.com> (raw)
In-Reply-To: <20190213173650.GA26078@linux.ibm.com>
From: Alan Stern <stern@rowland.harvard.edu>
In preparation for adding support for SRCU, rename "crit" to
"rcu-rscs", rename "rscs" to "rcu-rscsi", and remove the restriction
to only the outermost level of nesting.
The name change is needed for disambiguating RCU read-side critical
sections from SRCU read-side critical sections. Adding the "i" at the
end of "rcu-rscsi" emphasizes that the relation is inverted; it links
rcu_read_unlock() events to their corresponding preceding
rcu_read_lock() events.
The restriction to outermost nesting levels was never essential; it
was included mostly to show that it could be done. Rather than add
equivalent unnecessary code for SRCU lock nesting, it seemed better to
remove the existing code.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Tested-by: Andrea Parri <andrea.parri@amarulasolutions.com>
---
tools/memory-model/linux-kernel.bell | 9 +++------
tools/memory-model/linux-kernel.cat | 10 +++++-----
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/tools/memory-model/linux-kernel.bell b/tools/memory-model/linux-kernel.bell
index 796513362c05..353c8d68e030 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -34,7 +34,7 @@ enum Barriers = 'wmb (*smp_wmb*) ||
instructions F[Barriers]
(* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
-let matched = let rec
+let rcu-rscs = let rec
unmatched-locks = Rcu-lock \ domain(matched)
and unmatched-unlocks = Rcu-unlock \ range(matched)
and unmatched = unmatched-locks | unmatched-unlocks
@@ -46,8 +46,5 @@ let matched = let rec
in matched
(* Validate nesting *)
-flag ~empty Rcu-lock \ domain(matched) as unbalanced-rcu-locking
-flag ~empty Rcu-unlock \ range(matched) as unbalanced-rcu-locking
-
-(* Outermost level of nesting only *)
-let crit = matched \ (po^-1 ; matched ; po^-1)
+flag ~empty Rcu-lock \ domain(rcu-rscs) as unbalanced-rcu-locking
+flag ~empty Rcu-unlock \ range(rcu-rscs) as unbalanced-rcu-locking
diff --git a/tools/memory-model/linux-kernel.cat b/tools/memory-model/linux-kernel.cat
index 8f23c74a96fd..ab9de9c1234b 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -95,7 +95,7 @@ acyclic pb as propagation
* onward on the one hand and from the rcu_read_unlock() backwards on the
* other hand.
*)
-let rscs = po ; crit^-1 ; po?
+let rcu-rscsi = po ; rcu-rscs^-1 ; po?
(*
* The synchronize_rcu() strong fence is special in that it can order not
@@ -109,10 +109,10 @@ let rcu-link = hb* ; pb* ; prop
* critical sections (joined by rcu-link) acts as a generalized strong fence.
*)
let rec rcu-fence = gp |
- (gp ; rcu-link ; rscs) |
- (rscs ; rcu-link ; gp) |
- (gp ; rcu-link ; rcu-fence ; rcu-link ; rscs) |
- (rscs ; rcu-link ; rcu-fence ; rcu-link ; gp) |
+ (gp ; rcu-link ; rcu-rscsi) |
+ (rcu-rscsi ; rcu-link ; gp) |
+ (gp ; rcu-link ; rcu-fence ; rcu-link ; rcu-rscsi) |
+ (rcu-rscsi ; rcu-link ; rcu-fence ; rcu-link ; gp) |
(rcu-fence ; rcu-link ; rcu-fence)
(* rb orders instructions just as pb does *)
--
2.17.1
next prev parent reply other threads:[~2019-02-13 17:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 17:36 [PATCH memory-model 0/7] LKMM updates for v5.1 Paul E. McKenney
2019-02-13 17:36 ` Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney [this message]
2019-02-13 17:37 ` [PATCH memory-model 1/7] tools/memory-model: Rename some RCU relations Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 2/7] tools/memory-model: Refactor " Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 3/7] tools/memory-model: Add SRCU support Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 4/7] tools/memory-model: Update README for addition of SRCU Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 5/7] tools/memory-model: Update Documentation/explanation.txt to include SRCU support Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 6/7] tools/memory-model: Dynamically check SRCU lock-to-unlock matching Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
2019-02-13 17:37 ` [PATCH memory-model 7/7] tools/memory-model: Avoid duplicating herdtools versions Paul E. McKenney
2019-02-13 17:37 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190213173743.26682-1-paulmck@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox