Messages in this thread Patch in this message | | | Date | Sat, 25 Feb 2023 19:09:05 -0800 | From | Boqun Feng <> | Subject | Re: [PATCH v3] tools/memory-model: Make ppo a subrelation of po |
| |
On Sat, Feb 25, 2023 at 09:29:51PM -0500, Alan Stern wrote: > On Sat, Feb 25, 2023 at 05:01:10PM -0800, Paul E. McKenney wrote: > > A few other oddities: > > > > litmus/auto/C-LB-Lww+R-OC.litmus > > > > Both versions flag a data race, which I am not seeing. It appears > > to me that P1's store to u0 cannot happen unless P0's store > > has completed. So what am I missing here? > > The LKMM doesn't believe that a control or data dependency orders a > plain write after a marked read. Hence in this test it thinks that P1's > store to u0 can happen before the load of x1. I don't remember why we > did it this way -- probably we just wanted to minimize the restrictions > on when plain accesses can execute. (I do remember the reason for > making address dependencies induce order; it was so RCU would work.) >
Because plain store can be optimzed as an "store only if not equal"? As the following sentenses in the explanations.txt:
The need to distinguish between r- and w-bounding raises yet another issue. When the source code contains a plain store, the compiler is allowed to put plain loads of the same location into the object code. For example, given the source code:
x = 1;
the compiler is theoretically allowed to generate object code that looks like:
if (x != 1) x = 1;
thereby adding a load (and possibly replacing the store entirely). For this reason, whenever the LKMM requires a plain store to be w-pre-bounded or w-post-bounded by a marked access, it also requires the store to be r-pre-bounded or r-post-bounded, so as to handle cases where the compiler adds a load.
Regards, Boqun
> The patch below will change what the LKMM believes. It eliminates the > positive outcome of the litmus test and the data race. Should it be > adopted into the memory model? > > > litmus/auto/C-LB-Lrw+R-OC.litmus > > litmus/auto/C-LB-Lww+R-Oc.litmus > > litmus/auto/C-LB-Lrw+R-Oc.litmus > > litmus/auto/C-LB-Lrw+R-A+R-Oc.litmus > > litmus/auto/C-LB-Lww+R-A+R-OC.litmus > > > > Ditto. (There are likely more.) > > I haven't looked at these but they're probably similar. > > Alan > > > > --- usb-devel.orig/tools/memory-model/linux-kernel.cat > +++ usb-devel/tools/memory-model/linux-kernel.cat > @@ -172,7 +172,7 @@ let vis = cumul-fence* ; rfe? ; [Marked] > ((strong-fence ; [Marked] ; xbstar) | (xbstar & int)) > > (* Boundaries for lifetimes of plain accesses *) > -let w-pre-bounded = [Marked] ; (addr | fence)? > +let w-pre-bounded = [Marked] ; (rwdep | fence)? > let r-pre-bounded = [Marked] ; (addr | nonrw-fence | > ([R4rmb] ; fencerel(Rmb) ; [~Noreturn]))? > let w-post-bounded = fence? ; [Marked] ; rmw-sequence
| |