From: Paul E. McKenney Date: Tue, 26 Jan 2016 06:12:34 +0000 (-0800) Subject: documentation: Add alternative release-acquire outcome X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=37ef0341ca60b364dde05239c98b15c999195d8c;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git documentation: Add alternative release-acquire outcome The memory-barriers.txt discussion of local transitivity and release-acquire chains leaves out discussion of the outcome of the read from "u". This commit therefore adds an outcome showing that you can get a "1" from this read even if the release-acquire pairs don't line up. Reported-by: Will Deacon Signed-off-by: Paul E. McKenney --- diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index ae9d306725ba..57e4a4b053c5 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1372,6 +1372,10 @@ is possible: r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 +As an aside, the following outcome is also possible: + + r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1 + Although cpu0(), cpu1(), and cpu2() will see their respective reads and writes in order, CPUs not involved in the release-acquire chain might well disagree on the order. This disagreement stems from the fact that