This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: Implement membarrier function
- From: Alan Stern <stern at rowland dot harvard dot edu>
- To: "Paul E. McKenney" <paulmck at linux dot ibm dot com>
- Cc: David Goldblatt <davidtgoldblatt at gmail dot com>, <mathieu dot desnoyers at efficios dot com>, Florian Weimer <fweimer at redhat dot com>, <triegel at redhat dot com>, <libc-alpha at sourceware dot org>, <andrea dot parri at amarulasolutions dot com>, <will dot deacon at arm dot com>, <peterz at infradead dot org>, <boqun dot feng at gmail dot com>, <npiggin at gmail dot com>, <dhowells at redhat dot com>, <j dot alglave at ucl dot ac dot uk>, <luc dot maranget at inria dot fr>, <akiyks at gmail dot com>, <dlustig at nvidia dot com>, <linux-arch at vger dot kernel dot org>, <linux-kernel at vger dot kernel dot org>
- Date: Wed, 12 Dec 2018 17:12:18 -0500 (EST)
- Subject: Re: [PATCH] Linux: Implement membarrier function
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