Hi, Paul,
I noticed that in the control dependency section in
memory-barrier.txt, you mistakenly made an inconsistent
description:
On the description part:
641 It is tempting to try to enforce ordering on identical stores on both
642 branches of the "if" statement as follows:
643
644 q = READ_ONCE(a);
645 if (q) {
646 barrier();
647 WRITE_ONCE(b, p);
648 do_something();
649 } else {
650 barrier();
651 WRITE_ONCE(b, p);
652 do_something_else();
653 }
654
655 Unfortunately, current compilers will transform this as follows at high
656 optimization levels:
657
658 q = READ_ONCE(a);
659 barrier();
660 WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */
661 if (q) {
662 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
663 do_something();
664 } else {
665 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
666 do_something_else();
667 }
668
This part is incorporated in commit 2456d2a617de ("memory-barriers: Fix
description of 2-legged-if-based control dependencies") on 2014-08-13.
However, on the summary part:
803 (*) If both legs of the "if" statement begin with identical stores
804 to the same variable, a barrier() statement is required at the
805 beginning of each leg of the "if" statement.
This part is incorporated in commit 9b2b3bf53124
("Documentation/memory-barriers.txt:
Need barriers() for some control dependencies"), on 2014-02-12.
I think you missed fixing the summary part?
Thanks,
Jianyu Zhan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
