memory-model/Documentation/explanation.txt

157 Some predictions are trivial.  For instance, no sane memory model would
170 unconditionally then we would instead have r1 = 0 and r2 = 1.)
173 If this were to occur it would mean the driver contains a bug, because
174 incorrect data would get sent to the user: 0 instead of 1.  As it
203 	would be 1 since a load obtains its value from the most recent
213 Consistency memory model; doing so would rule out too many valuable
266 Z ordered before X, because this would mean that X is ordered before
278 if those accesses would form a cycle, then the memory model predicts
410 Given this version of the code, the LKMM would predict that the load
620 If the final value stored in x after this code ran was 17, you would
621 think your computer was broken.  It would be a violation of the
636 If r1 = 666 at the end, this would violate the read-write coherence
659 would violate the read-read coherence rule: The r1 load comes before
707 stores to x, there would also be fr links from the READ_ONCE() to
1056 If it executed W first then the memory subsystem would respond to R's
1062 and the CPU executed W' before W, then the memory subsystem would put
1063 W' before W in the coherence order.  It would effectively cause W to
1139 then we would never get r1 = &x and r2 = 0.  By the time P1 executed
1140 its second load, the x = 1 store would already be fully processed by
1218 had executed before its store then the value of the store would have
1219 been forwarded to the load, so r1 would have ended up equal to 1, not
1245 load executed, and so r1 would have been 9 rather than 0.  In this
1282 from flag were executed first, then the buf = 1 store would already
1284 would have been 1 at the end, not 0.  (The reasoning holds even for
1289 would force the two loads to be executed in program order, and it
1290 would generate a cycle in the hb relation: The fence would create a ppo
1292 prop relation would give an hb link from the second load to the first.
1381 before F.  To see why, suppose that F executed first.  Then W would
1383 memory subsystem would then be forced to make E come after W in the
1385 load, the memory subsystem would then be forced to satisfy E's read
1420 to P0's.  This means that if both r1 and r2 were 0 there would be a
1548 would imply that X ->rcu-order V, because this sequence contains two
1704 allowed by the LKMM, as we would expect.
1793 An alternate way to express the same thing would be:
1818 execute before any instruction po-after the lock-acquire.  This would
1864 Then the CPU would be allowed to forward the s = 1 value from the
1956 On the face of it, one would expect that when this code runs, the only
1977 the compiler would not have performed this optimization and there
1978 would be no possibility of a NULL-pointer dereference.
1983 violates the compiler's assumptions, which would render the ultimate
2032 could very well interfere somehow with Y, and we would have to
2124 race (if it could, memory models would be useless and no multithreaded
2125 code would be safe!).  For another, it cannot move a plain access past
2146 there would be no such guarantee; the two groups of accesses could be
2211 X ->xb* E.  If E was also a plain access, we would also look for a
2217 "r-post-bounded" by X.  Similarly, E would be "r-pre-bounded" or
2246 Linux kernel developers would probably fight pretty hard to change a
2272 assumption like this one, some usages typical of RCU would count as
2297 included merely for the sake of good form; typically P0 would call
2330 which would invalidate the memory model's assumption, since the CPU
2362 Guarantee says that otherwise P0's store to x would have propagated to
2363 P1 before the critical section started and so would have been visible