Re: Trial of conflict resolution of Alan's patch
On Fri, Feb 16, 2018 at 04:47:04PM +0100, Andrea Parri wrote: > On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote: > > On Fri, 16 Feb 2018, Akira Yokosawa wrote: > > > > > Hi, > > > > > > My forward-port patch doesn't apply to the "lkmm" branch. > > > It looks like "linux-kernel-hardware.cat" is intentionally omitted there. > > > Am I guessing right? > > > > > > If this is the case, I can prepare a patch to be applied to "lkmm". > > > But I can't compose a proper change log. So I'd like Alan to post > > > a patch with my SOB appended. Does this approach sound reasonable? > > > > The patch is not yet ready to be merged. At the very least, I need to > > include an update to explanation.txt along with it. When it is all > > ready, I will rebase it on Paul's repository and post it. > > > > Which reminds me: Now that the material has been accepted into the > > kernel, do we need to keep the github repository? It has the > > linux-kernel-hardware.cat file, but otherwise it seems to be redundant. > > If you mean "to keep up-to-date", I'd say "No, we don't..." ;-) > > My plan/hope is to add such a disclaimer together with a pointer > to Linus's tree ASAP... I agree that the github repository is useful as a historical reference but that we should not try to keep it up to date. The -rc1 release came out last Sunday, so in 7-8 weeks we will hopefully have this in the Linux kernel. Fingers firmly crossed and all that... Thanx, Paul
Re: Trial of conflict resolution of Alan's patch
On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote: > On Fri, 16 Feb 2018, Akira Yokosawa wrote: > > > Hi, > > > > My forward-port patch doesn't apply to the "lkmm" branch. > > It looks like "linux-kernel-hardware.cat" is intentionally omitted there. > > Am I guessing right? > > > > If this is the case, I can prepare a patch to be applied to "lkmm". > > But I can't compose a proper change log. So I'd like Alan to post > > a patch with my SOB appended. Does this approach sound reasonable? > > The patch is not yet ready to be merged. At the very least, I need to > include an update to explanation.txt along with it. When it is all > ready, I will rebase it on Paul's repository and post it. > > Which reminds me: Now that the material has been accepted into the > kernel, do we need to keep the github repository? It has the > linux-kernel-hardware.cat file, but otherwise it seems to be redundant. If you mean "to keep up-to-date", I'd say "No, we don't..." ;-) My plan/hope is to add such a disclaimer together with a pointer to Linus's tree ASAP... Andrea > > Alan >
Re: Trial of conflict resolution of Alan's patch
On Fri, 16 Feb 2018, Akira Yokosawa wrote: > Hi, > > My forward-port patch doesn't apply to the "lkmm" branch. > It looks like "linux-kernel-hardware.cat" is intentionally omitted there. > Am I guessing right? > > If this is the case, I can prepare a patch to be applied to "lkmm". > But I can't compose a proper change log. So I'd like Alan to post > a patch with my SOB appended. Does this approach sound reasonable? The patch is not yet ready to be merged. At the very least, I need to include an update to explanation.txt along with it. When it is all ready, I will rebase it on Paul's repository and post it. Which reminds me: Now that the material has been accepted into the kernel, do we need to keep the github repository? It has the linux-kernel-hardware.cat file, but otherwise it seems to be redundant. Alan
Re: Trial of conflict resolution of Alan's patch
On Thu, Feb 15, 2018 at 11:05:39PM +0100, Andrea Parri wrote:
> On Thu, Feb 15, 2018 at 11:29:14AM -0800, Paul E. McKenney wrote:
> > On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
> > > On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> > >
> > > > So, I attempted to rebase the patch to current (somewhat old) master of
> > > > https://github.com/aparri/memory-model. Why? Because the lkmm branch
> > > > in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
> > > >
> > > > However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
> > > > has the result "Sometimes". I must have done something wrong in the
> > > > conflict resolution.
> > > >
> > > > Note: I have almost no idea what this patch is doing. I'm just hoping
> > > > to give a starting point of a discussion.
> > >
> > > Yes, that litmus test gives "Sometimes" both with and without the
> > > patch. But consider instead this slightly changed version of that
> > > test, in which P2 reads Z instead of writing it:
> > >
> > > C Z6.0-variant
> > >
> > > {}
> > >
> > > P0(int *x, int *y, spinlock_t *mylock)
> > > {
> > > spin_lock(mylock);
> > > WRITE_ONCE(*x, 1);
> > > WRITE_ONCE(*y, 1);
> > > spin_unlock(mylock);
> > > }
> > >
> > > P1(int *y, int *z, spinlock_t *mylock)
> > > {
> > > int r0;
> > >
> > > spin_lock(mylock);
> > > r0 = READ_ONCE(*y);
> > > WRITE_ONCE(*z, 1);
> > > spin_unlock(mylock);
> > > }
> > >
> > > P2(int *x, int *z)
> > > {
> > > int r1;
> > > int r2;
> > >
> > > r2 = READ_ONCE(*z);
> > > smp_mb();
> > > r1 = READ_ONCE(*x);
> > > }
> > >
> > > exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
> > >
> > > Without the patch, this test gives "Sometimes"; with the patch it gives
> > > "Never". That is what I thought Paul was talking about originally.
> > >
> > > Sorry if my misunderstanding caused too much confusion for other
> > > people.
> >
> > Ah, I did indeed get confused. I have changed the "Result:" for
> > Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
> > the patch below (which I merged into the patch adding all the
> > comments).
> >
> > I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
> > with the Result: of Sometimes with you (Alan) as author and with your
> > Signed-off-by -- please let me know if you would prefer some other
> > approach.
> >
> > Please change the Result: when sending the proposed patch. Or please let
> > me know if you would like me to apply the forward-port that Akira sent,
> > in which case I will add the Result: change to that patch. Or for that
> > matter, Akira might repost his forward-port of your patch with this change.
> >
> > Thanx, Paul
> >
> >
> >
> > commit b2950420e1154131c0667f1ac58666bad3a06a69
> > Author: Paul E. McKenney
> > Date: Thu Feb 15 10:35:25 2018 -0800
> >
> > fixup! EXP litmus_tests: Add comments explaining tests' purposes
> >
> > Signed-off-by: Paul E. McKenney
> >
> > diff --git
> > a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> >
> > b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> > index fad47258a3e3..95890669859b 100644
> > ---
> > a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> > +++
> > b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> > @@ -1,7 +1,7 @@
> > C Z6.0+pooncelock+pooncelock+pombonce
> >
> > (*
> > - * Result: Never
> > + * Result: Somtimes
>
> nit: s/Somtimes/Sometimes
Good catch, fixed!
Thanx, Paul
> Andrea
>
>
> > *
> > * This example demonstrates that a pair of accesses made by different
> > * processes each while holding a given lock will not necessarily be
> >
>
Re: Trial of conflict resolution of Alan's patch
On Thu, Feb 15, 2018 at 11:29:14AM -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
> > On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> >
> > > So, I attempted to rebase the patch to current (somewhat old) master of
> > > https://github.com/aparri/memory-model. Why? Because the lkmm branch
> > > in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
> > >
> > > However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
> > > has the result "Sometimes". I must have done something wrong in the
> > > conflict resolution.
> > >
> > > Note: I have almost no idea what this patch is doing. I'm just hoping
> > > to give a starting point of a discussion.
> >
> > Yes, that litmus test gives "Sometimes" both with and without the
> > patch. But consider instead this slightly changed version of that
> > test, in which P2 reads Z instead of writing it:
> >
> > C Z6.0-variant
> >
> > {}
> >
> > P0(int *x, int *y, spinlock_t *mylock)
> > {
> > spin_lock(mylock);
> > WRITE_ONCE(*x, 1);
> > WRITE_ONCE(*y, 1);
> > spin_unlock(mylock);
> > }
> >
> > P1(int *y, int *z, spinlock_t *mylock)
> > {
> > int r0;
> >
> > spin_lock(mylock);
> > r0 = READ_ONCE(*y);
> > WRITE_ONCE(*z, 1);
> > spin_unlock(mylock);
> > }
> >
> > P2(int *x, int *z)
> > {
> > int r1;
> > int r2;
> >
> > r2 = READ_ONCE(*z);
> > smp_mb();
> > r1 = READ_ONCE(*x);
> > }
> >
> > exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
> >
> > Without the patch, this test gives "Sometimes"; with the patch it gives
> > "Never". That is what I thought Paul was talking about originally.
> >
> > Sorry if my misunderstanding caused too much confusion for other
> > people.
>
> Ah, I did indeed get confused. I have changed the "Result:" for
> Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
> the patch below (which I merged into the patch adding all the
> comments).
>
> I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
> with the Result: of Sometimes with you (Alan) as author and with your
> Signed-off-by -- please let me know if you would prefer some other
> approach.
>
> Please change the Result: when sending the proposed patch. Or please let
> me know if you would like me to apply the forward-port that Akira sent,
> in which case I will add the Result: change to that patch. Or for that
> matter, Akira might repost his forward-port of your patch with this change.
>
> Thanx, Paul
>
>
>
> commit b2950420e1154131c0667f1ac58666bad3a06a69
> Author: Paul E. McKenney
> Date: Thu Feb 15 10:35:25 2018 -0800
>
> fixup! EXP litmus_tests: Add comments explaining tests' purposes
>
> Signed-off-by: Paul E. McKenney
>
> diff --git
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> index fad47258a3e3..95890669859b 100644
> ---
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> +++
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> @@ -1,7 +1,7 @@
> C Z6.0+pooncelock+pooncelock+pombonce
>
> (*
> - * Result: Never
> + * Result: Somtimes
nit: s/Somtimes/Sometimes
Andrea
> *
> * This example demonstrates that a pair of accesses made by different
> * processes each while holding a given lock will not necessarily be
>
Re: Trial of conflict resolution of Alan's patch
On 2018/02/15 11:29:14 -0800, Paul E. McKenney wrote:
> On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
>> On Fri, 16 Feb 2018, Akira Yokosawa wrote:
>>
>>> So, I attempted to rebase the patch to current (somewhat old) master of
>>> https://github.com/aparri/memory-model. Why? Because the lkmm branch
>>> in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
>>>
>>> However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
>>> has the result "Sometimes". I must have done something wrong in the
>>> conflict resolution.
>>>
>>> Note: I have almost no idea what this patch is doing. I'm just hoping
>>> to give a starting point of a discussion.
>>
>> Yes, that litmus test gives "Sometimes" both with and without the
>> patch. But consider instead this slightly changed version of that
>> test, in which P2 reads Z instead of writing it:
>>
>> C Z6.0-variant
>>
>> {}
>>
>> P0(int *x, int *y, spinlock_t *mylock)
>> {
>> spin_lock(mylock);
>> WRITE_ONCE(*x, 1);
>> WRITE_ONCE(*y, 1);
>> spin_unlock(mylock);
>> }
>>
>> P1(int *y, int *z, spinlock_t *mylock)
>> {
>> int r0;
>>
>> spin_lock(mylock);
>> r0 = READ_ONCE(*y);
>> WRITE_ONCE(*z, 1);
>> spin_unlock(mylock);
>> }
>>
>> P2(int *x, int *z)
>> {
>> int r1;
>> int r2;
>>
>> r2 = READ_ONCE(*z);
>> smp_mb();
>> r1 = READ_ONCE(*x);
>> }
>>
>> exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
>>
>> Without the patch, this test gives "Sometimes"; with the patch it gives
>> "Never". That is what I thought Paul was talking about originally.
>>
>> Sorry if my misunderstanding caused too much confusion for other
>> people.
>
> Ah, I did indeed get confused. I have changed the "Result:" for
> Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
> the patch below (which I merged into the patch adding all the
> comments).
>
> I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
> with the Result: of Sometimes with you (Alan) as author and with your
> Signed-off-by -- please let me know if you would prefer some other
> approach.
>
> Please change the Result: when sending the proposed patch. Or please let
> me know if you would like me to apply the forward-port that Akira sent,
> in which case I will add the Result: change to that patch. Or for that
> matter, Akira might repost his forward-port of your patch with this change.
>
Hi,
My forward-port patch doesn't apply to the "lkmm" branch.
It looks like "linux-kernel-hardware.cat" is intentionally omitted there.
Am I guessing right?
If this is the case, I can prepare a patch to be applied to "lkmm".
But I can't compose a proper change log. So I'd like Alan to post
a patch with my SOB appended. Does this approach sound reasonable?
Thanks, Akira
> Thanx, Paul
>
>
>
> commit b2950420e1154131c0667f1ac58666bad3a06a69
> Author: Paul E. McKenney
> Date: Thu Feb 15 10:35:25 2018 -0800
>
> fixup! EXP litmus_tests: Add comments explaining tests' purposes
>
> Signed-off-by: Paul E. McKenney
>
> diff --git
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> index fad47258a3e3..95890669859b 100644
> ---
> a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> +++
> b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
> @@ -1,7 +1,7 @@
> C Z6.0+pooncelock+pooncelock+pombonce
>
> (*
> - * Result: Never
> + * Result: Somtimes
> *
> * This example demonstrates that a pair of accesses made by different
> * processes each while holding a given lock will not necessarily be
>
Re: Trial of conflict resolution of Alan's patch
On Thu, Feb 15, 2018 at 12:51:56PM -0500, Alan Stern wrote:
> On Fri, 16 Feb 2018, Akira Yokosawa wrote:
>
> > So, I attempted to rebase the patch to current (somewhat old) master of
> > https://github.com/aparri/memory-model. Why? Because the lkmm branch
> > in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
> >
> > However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
> > has the result "Sometimes". I must have done something wrong in the
> > conflict resolution.
> >
> > Note: I have almost no idea what this patch is doing. I'm just hoping
> > to give a starting point of a discussion.
>
> Yes, that litmus test gives "Sometimes" both with and without the
> patch. But consider instead this slightly changed version of that
> test, in which P2 reads Z instead of writing it:
>
> C Z6.0-variant
>
> {}
>
> P0(int *x, int *y, spinlock_t *mylock)
> {
> spin_lock(mylock);
> WRITE_ONCE(*x, 1);
> WRITE_ONCE(*y, 1);
> spin_unlock(mylock);
> }
>
> P1(int *y, int *z, spinlock_t *mylock)
> {
> int r0;
>
> spin_lock(mylock);
> r0 = READ_ONCE(*y);
> WRITE_ONCE(*z, 1);
> spin_unlock(mylock);
> }
>
> P2(int *x, int *z)
> {
> int r1;
> int r2;
>
> r2 = READ_ONCE(*z);
> smp_mb();
> r1 = READ_ONCE(*x);
> }
>
> exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
>
> Without the patch, this test gives "Sometimes"; with the patch it gives
> "Never". That is what I thought Paul was talking about originally.
>
> Sorry if my misunderstanding caused too much confusion for other
> people.
Ah, I did indeed get confused. I have changed the "Result:" for
Z6.0+pooncelock+pooncelock+pombonce.litmus back to "Never", as in
the patch below (which I merged into the patch adding all the
comments).
I have added the above test as ISA2+pooncelock+pooncelock+pombonce.litmus,
with the Result: of Sometimes with you (Alan) as author and with your
Signed-off-by -- please let me know if you would prefer some other
approach.
Please change the Result: when sending the proposed patch. Or please let
me know if you would like me to apply the forward-port that Akira sent,
in which case I will add the Result: change to that patch. Or for that
matter, Akira might repost his forward-port of your patch with this change.
Thanx, Paul
commit b2950420e1154131c0667f1ac58666bad3a06a69
Author: Paul E. McKenney
Date: Thu Feb 15 10:35:25 2018 -0800
fixup! EXP litmus_tests: Add comments explaining tests' purposes
Signed-off-by: Paul E. McKenney
diff --git
a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
index fad47258a3e3..95890669859b 100644
--- a/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
+++ b/tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus
@@ -1,7 +1,7 @@
C Z6.0+pooncelock+pooncelock+pombonce
(*
- * Result: Never
+ * Result: Somtimes
*
* This example demonstrates that a pair of accesses made by different
* processes each while holding a given lock will not necessarily be
Re: Trial of conflict resolution of Alan's patch
On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> So, I attempted to rebase the patch to current (somewhat old) master of
> https://github.com/aparri/memory-model. Why? Because the lkmm branch
> in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
>
> However, after this change, Z6.0+pooncelock+pooncelock+pombonce still
> has the result "Sometimes". I must have done something wrong in the
> conflict resolution.
>
> Note: I have almost no idea what this patch is doing. I'm just hoping
> to give a starting point of a discussion.
Yes, that litmus test gives "Sometimes" both with and without the
patch. But consider instead this slightly changed version of that
test, in which P2 reads Z instead of writing it:
C Z6.0-variant
{}
P0(int *x, int *y, spinlock_t *mylock)
{
spin_lock(mylock);
WRITE_ONCE(*x, 1);
WRITE_ONCE(*y, 1);
spin_unlock(mylock);
}
P1(int *y, int *z, spinlock_t *mylock)
{
int r0;
spin_lock(mylock);
r0 = READ_ONCE(*y);
WRITE_ONCE(*z, 1);
spin_unlock(mylock);
}
P2(int *x, int *z)
{
int r1;
int r2;
r2 = READ_ONCE(*z);
smp_mb();
r1 = READ_ONCE(*x);
}
exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
Without the patch, this test gives "Sometimes"; with the patch it gives
"Never". That is what I thought Paul was talking about originally.
Sorry if my misunderstanding caused too much confusion for other
people.
Alan
Trial of conflict resolution of Alan's patch
>From 81bd6374057f0d89894ead482b870e2f001d2998 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Fri, 16 Feb 2018 00:29:56 +0900 Subject: [PATCH] [TENTATIVE] Trial conflict resolution of Alan's patch This is a trial of conflict resolution of the patch Alan provided. Alan's message and original patch: Here's the relevant patch. It may need some manual adjustment, because it was not made against the files currently in the repository. Alan diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat Index: memory-model/linux-kernel-hardware.cat === --- memory-model.orig/linux-kernel-hardware.cat +++ memory-model/linux-kernel-hardware.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -57,13 +57,13 @@ let to-w = rwdep | addrpo | (overwrite & let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let rec prop = (overwrite & ext)? ; cumul-fence ; hb* and hb = ppo | rfe | ((hb* ; prop) & int) Index: memory-model/linux-kernel.cat === --- memory-model.orig/linux-kernel.cat +++ memory-model/linux-kernel.cat @@ -31,7 +31,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -54,13 +54,13 @@ let rwdep = (dep | ctrl) ; [W] let overwrite = co | fr let to-w = rwdep | (overwrite & int) let rrdep = addr | (dep ; rfi) -let to-r = rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = to-r | to-w | fence (* Propagation: Ordering from release operations and strong fences. *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let prop = (overwrite & ext)? ; cumul-fence* ; rfe? (* Signed-off-by: Alan Stern [akiyks: Rebased to current master] Signed-off-by: Akira Yokosawa --- So, I attempted to rebase the patch to current (somewhat old) master of https://github.com/aparri/memory-model. Why? Because the lkmm branch in Paul's -rcu tree doesn't have linux-kernel-hardware.cat. However, after this change, Z6.0+pooncelock+pooncelock+pombonce still has the result "Sometimes". I must have done something wrong in the conflict resolution. Note: I have almost no idea what this patch is doing. I'm just hoping to give a starting point of a discussion. Thanks, Akira -- linux-kernel-hardware.cat | 9 - linux-kernel.cat | 9 - 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/linux-kernel-hardware.cat b/linux-kernel-hardware.cat index 7768bf7..6c35655 100644 --- a/linux-kernel-hardware.cat +++ b/linux-kernel-hardware.cat @@ -34,7 +34,7 @@ let strong-fence = mb | gp (* Release Acquire *) let acq-po = [Acquire] ; po ; [M] let po-rel = [M] ; po ; [Release] -let rfi-rel-acq = [Release] ; rfi ; [Acquire] +let rel-rf-acq-po = [Release] ; rf ; [Acquire] ; po (**) (* Fundamental coherence ordering *) @@ -60,14 +60,13 @@ let to-w = rwdep | addrpo | (overwrite & int) let rdw = po-loc & (fre ; rfe) let detour = po-loc & (coe ; rfe) let rrdep = addr | (dep ; rfi) | rdw -let strong-rrdep = rrdep+ & rb-dep -let to-r = strong-rrdep | rfi-rel-acq -let fence = strong-fence | wmb | po-rel | rmb | acq-po +let to-r = rrdep +let fence = strong-fence | wmb | po-rel | rmb | acq-po | (rel-rf-acq-po & int) let ppo = (rrdep* ; (to-r | to-w | fence)) | rdw | detour (* Happens Before *) let A-cumul(r) = rfe? ; r -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | rel-rf-acq-po let rec prop = (overwrite & ext)? ; cumul-fence ; hb* and hb = pp
