public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
	Andrea Parri <parri.andrea@gmail.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/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence
Date: Thu, 1 Mar 2018 20:50:15 -0800	[thread overview]
Message-ID: <20180302045015.GO3777@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180302043141.fgmjyysrws55pi7q@tardis>

On Fri, Mar 02, 2018 at 12:31:41PM +0800, Boqun Feng wrote:
> On Thu, Mar 01, 2018 at 10:37:58AM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 01, 2018 at 09:49:06AM -0800, Paul E. McKenney wrote:

[ . . . ]

> > And as Andrea pointed out off-list, I did indeed mess up Boqun's change.
> > I forgot to change the "irreflexive" into "acyclic".  Applying that change
> > makes everything work.
> > 
> > Please accept my apologies for my confusion!
> > 
> 
> np, also I should have provided a proper patch for your testing.
> 
> For this Alan's patch, feel free to add:
> 
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>

Alan's last submission was still RFC, so I have not yet queued it.
So this ball is still in Alan's court.

							Thanx, Paul

> Regards,
> Boqun
> 
> > 							Thanx, Paul
> > 
> > > > > I prefer this because we already treat "gp" as "strong-fence", which
> > > > > already is a "rcu-link".
> > > > 
> > > > That's a good point; it had not occurred to me.
> > > 
> > > And if I remove the "gp" but leave the last line, it does properly
> > > classify the two new litmus tests.
> > > 
> > > 							Thanx, Paul
> > > 
> > > > >  Also, recurisively extending rcu-fence with
> > > > > itself is exactly calculating the transitive closure, which we can avoid
> > > > > by using a "acycle" rule. Besides, it looks more consistent with hb and
> > > > > pb.
> > > > 
> > > > That _had_ occurred to me.  But I couldn't see any way to do it while 
> > > > still defining rcu-fence correctly.
> > > 
> > > ------------------------------------------------------------------------
> > > 
> > > diff --git a/tools/memory-model/linux-kernel.cat b/tools/memory-model/linux-kernel.cat
> > > index 1e5c4653dd12..75d3c225146c 100644
> > > --- a/tools/memory-model/linux-kernel.cat
> > > +++ b/tools/memory-model/linux-kernel.cat
> > > @@ -106,12 +106,11 @@ let rcu-link = 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.
> > >   *)
> > > -let rec rcu-fence = gp |
> > > +let rec rcu-fence =
> > >  	(gp ; rcu-link ; rscs) |
> > >  	(rscs ; rcu-link ; gp) |
> > >  	(gp ; rcu-link ; rcu-fence ; rcu-link ; rscs) |
> > > -	(rscs ; rcu-link ; rcu-fence ; rcu-link ; gp) |
> > > -	(rcu-fence ; rcu-link ; rcu-fence)
> > > +	(rscs ; rcu-link ; rcu-fence ; rcu-link ; gp)
> > >  
> > >  (* rb orders instructions just as pb does *)
> > >  let rb = prop ; rcu-fence ; hb* ; pb*
> > 

  reply	other threads:[~2018-03-02  4:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 20:13 [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence Alan Stern
2018-03-01  1:55 ` Boqun Feng
2018-03-01  4:49   ` Paul E. McKenney
2018-03-01  8:39     ` Boqun Feng
2018-03-01 14:28       ` Paul E. McKenney
2018-03-01 15:49   ` Alan Stern
2018-03-01 17:49     ` Paul E. McKenney
2018-03-01 18:37       ` Paul E. McKenney
2018-03-02  4:31         ` Boqun Feng
2018-03-02  4:50           ` Paul E. McKenney [this message]
2018-03-02 15:17             ` Alan Stern
2018-03-02 17:38               ` Paul E. McKenney
2018-03-13 13:56 ` Andrea Parri

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=20180302045015.GO3777@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --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