From: Boqun Feng <boqun.feng@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>,
LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
Andrea Parri <andrea.parri@amarulasolutions.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 2/3] tools/memory-model: Refactor some RCU relations
Date: Fri, 16 Nov 2018 01:54:20 +0800 [thread overview]
Message-ID: <20181115175420.GA3227@tardis> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1811151116420.1308-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]
Hi Alan,
On Thu, Nov 15, 2018 at 11:19:58AM -0500, Alan Stern wrote:
> In preparation for adding support for SRCU, refactor the definitions
> of rcu-fence, rcu-rscsi, rcu-link, and rb by moving the po and po?
> terms from the first two to the second two. An rcu-gp relation is
> added; it is equivalent to gp with the po and po? terms removed.
>
> This is necessary because for SRCU, we will have to use the loc
> relation to check that the terms at the start and end of each disjunct
> in the definition of rcu-fence refer to the same srcu_struct
> location. If these terms are hidden behind po and po?, there's no way
> to carry out this check.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>
> ---
>
>
> tools/memory-model/linux-kernel.cat | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> Index: usb-4.x/tools/memory-model/linux-kernel.cat
> ===================================================================
> --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
> +++ usb-4.x/tools/memory-model/linux-kernel.cat
> @@ -91,32 +91,37 @@ acyclic pb as propagation
> (*******)
>
> (*
> - * Effect of read-side critical section proceeds from the rcu_read_lock()
> - * onward on the one hand and from the rcu_read_unlock() backwards on the
> + * Effects of read-side critical sections proceed from the rcu_read_unlock()
> + * backwards on the one hand, and from the rcu_read_lock() forwards on the
> * other hand.
> + *
> + * In the definition of rcu-fence below, the po term at the left-hand side
> + * of each disjunct and the po? term at the right-hand end have been factored
> + * out. They have been moved into the definitions of rcu-link and rb.
> *)
> -let rcu-rscsi = po ; rcu-rscs^-1 ; po?
> +let rcu-gp = [Sync-rcu] (* Compare with gp *)
> +let rcu-rscsi = rcu-rscs^-1
Isn't it more straight-forward to use "rcu-rscs^-1" other than
"rcu-rscsi" in the definition of "rcu-fence", is it?
The introduction of "rcu-rscsi" makes sense in the first patch, but with
this refactoring, I think it's better we just don't use it.
Regards,
Boqun
>
> (*
> * The synchronize_rcu() strong fence is special in that it can order not
> * one but two non-rf relations, but only in conjunction with an RCU
> * read-side critical section.
> *)
> -let rcu-link = hb* ; pb* ; prop
> +let rcu-link = po? ; hb* ; pb* ; prop ; po
>
> (*
> * 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.
> *)
> -let rec rcu-fence = 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) |
> +let rec rcu-fence = rcu-gp |
> + (rcu-gp ; rcu-link ; rcu-rscsi) |
> + (rcu-rscsi ; rcu-link ; rcu-gp) |
> + (rcu-gp ; rcu-link ; rcu-fence ; rcu-link ; rcu-rscsi) |
> + (rcu-rscsi ; rcu-link ; rcu-fence ; rcu-link ; rcu-gp) |
> (rcu-fence ; rcu-link ; rcu-fence)
>
> (* rb orders instructions just as pb does *)
> -let rb = prop ; rcu-fence ; hb* ; pb*
> +let rb = prop ; po ; rcu-fence ; po? ; hb* ; pb*
>
> irreflexive rb as rcu
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-11-15 17:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 16:19 [PATCH 2/3] tools/memory-model: Refactor some RCU relations Alan Stern
2018-11-15 17:54 ` Boqun Feng [this message]
2018-11-15 19:12 ` Alan Stern
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=20181115175420.GA3227@tardis \
--to=boqun.feng@gmail.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=paulmck@linux.ibm.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