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/