> A couple of questions:> > - Would it be possible to include all the nice descriptions of the litmus tests in> the tests themselves? Right now it's a bit weird that most of them come with> zero explanations, but the tools/memory-model/litmus-tests/README lists most of> them.

Please see below for an initial patch to this effect. This activityproved to be more productive than expected for these tests, which certainlysupports our assertion that locking needs more testing...

MP+polocks.litmusMP+porevlocks.litmus

These are allowed by the current model, which surprised me a bit, given that even powerpc would forbid them. Is the rationale that a lock-savvy compiler could pull accesses into the lock's critical section and then reorder those accesses? Or does this constitute a bug in our model of locking?

(And these were allowed when I wrote recipes.txt, embarrassingly enough...)

Z6.0+pooncelock+poonceLock+pombonce.litmus

This was forbidden when I wrote recipes.txt, but now is allowed. The header comment for smp_mb__after_spinlock() makes it pretty clear that it must be forbidden. So this one is a bug in our model of locking.

I did not add comments to the above three, but please see below for apatch for the remaining litmus tests.

+(*+ * Test of read-write coherence, that is, whether or not a read from a+ * given variable followed by a write to that same variable are ordered.+ * This should be ordered, that is, this test should be forbidden.+ *)+ {}

+(*+ * Test of write-read coherence, that is, whether or not a write to a+ * given variable followed by a read from that same variable are ordered.+ * They should be ordered, that is, this test should be forbidden.+ *)+ {}

+(*+ * Test of independent reads from independent writes with smp_mb()+ * between each pairs of reads. In other words, is smp_mb() sufficient to+ * cause two different reading processes to agree on the order of a pair+ * of writes, where each write is to a different variable by a different+ * process? The smp_mb()s should be sufficient, that is, this test should+ * be forbidden.+ *)+ {}

+(*+ * Test of independent reads from independent writes with nothing+ * between each pairs of reads. In other words, is anything at all+ * needed to cause two different reading processes to agree on the order+ * of a pair of writes, where each write is to a different variable by a+ * different process? Something is needed, in other words, this test+ * should be allowed.+ *)+ {}

+(*+ * Given a release-acquire chain ordering the first process's store+ * against the last process's load, is ordering preserved if all of the+ * smp_store_release() invocations be replaced by WRITE_ONCE() and all+ * of the smp_load_acquire() invocations be replaced by READ_ONCE()?+ * The answer is "no", that is, this test should be allowed.+ *)+ {}

+(*+ * This litmus test demonstrates that a release-acquire chain suffices+ * to order P0()'s initial write against P2()'s final read. The reason+ * that the release-acquire chain suffices is because in all but one+ * case (P2() to P0()), each process reads from the preceding process's+ * write. In memory-model-speak, there is only one non-reads-from+ * (AKA non-rf) link, so release-acquire is all that is needed.+ *)+ {}

+(*+ * This litmus test demonstrates that lightweight ordering suffices for+ * the load-buffering pattern, in other words, preventing all processes+ * reading from the preceding process's write. In this example, the+ * combination of a control dependency and a full memory barrier are to do+ * the trick. (But the full memory barrier could be replaced with another+ * control dependency and order would still be maintained.)+ *)+ {}

+(*+ * Does a release-acquire pair suffice for the load-buffering litmus+ * test, where each process reads from one of two variables then writes+ * to the other? The answer is "yes", that is, this test should be+ * forbidden.+ *)+ {}

+(*+ * This litmus test demonstrates that smp_wmb() and smp_rmb() provide+ * sufficient ordering for the message-passing pattern. However, it+ * is usually better to use smp_store_release() and smp_load_acquire().+ *)+ {}

+(*+ * This is the fully ordered (via smp_mb()) version of one of the classic+ * counterintuitive litmus tests that illustrates the effects of store+ * propagation delays. This test should be forbidden, but weaking either+ * of the barriers would cause the resulting test to be allowed.+ *)+ {}

+(*+ * This is the unordered (via smp_mb()) version of one of the classic+ * counterintuitive litmus tests that illustrates the effects of store+ * propagation delays. This test should be allowed.+ *)+ {}

+(*+ * Starting with a two-process release-acquire chain ordering P0()'s+ * first store against P1()'s final load, if the smp_store_release()+ * is replaced by WRITE_ONCE() and the smp_load_acquire() replaced by+ * READ_ONCE(), is ordering preserved. The answer is "of course not!",+ * so this test should be allowed.+ *)+ {}

+(*+ * This litmus test demonstrates that full memory barriers suffice to+ * order the store-buffering pattern, where each process writes to the+ * variable that the preceding process read. (Locking and RCU can also+ * suffice, but not much else.)+ *)+ {}

+(*+ * This litmus test demonstrates that at least some ordering is required+ * to order the store-buffering pattern, where each process writes to the+ * variable that the preceding process read. This test should be allowed.+ *)+ {}

+(*+ * This litmus test is an extension of the message-passing pattern, where+ * the first write is moved to a separate process. But because this test+ * has no ordering at all, it should be allowed.+ *)+ {}

+(*+ * This litmus test is an extension of the message-passing pattern, where+ * the first write is moved to a separate process. Because it features+ * a release and a read memory barrier, it should be forbidden.+ *)+ {}

+(*+ * This example demonstrates that a pair of accesses made by different+ * processes each while holding a given lock will not necessarily be+ * seen as ordered by a third process not holding that lock.+ *)+ {}

+(*+ * This litmus test shows that a release-acquire chain, while sufficient+ * when there is but one non-reads-from (AKA non-rf) link, does not suffice+ * if there is more than one. Of the three processes, only P1() reads from+ * P0's write, which means that there are two non-rf links: P1() to P2()+ * is a write-to-write link (AKA a "coherence" or just "co" link) and P2()+ * to P0() is a read-to-write link (AKA a "from-reads" or just "fr" link).+ * When there are two or more non-rf links, you typically will need one+ * full barrier for each non-rf link. (Exceptions include some cases+ * involving locking.)+ *)+ {}