linux/Documentation/memory-barriers.txt

140 instructions it emits in any order it likes, provided it doesn't affect the
516 there won't be any such interaction in any particular piece of code, then
585 doesn't imply an address-dependency barrier.
599 isn't, and this behaviour can be observed on certain real CPUs (such as the DEC
630 because the CPUs that the Linux kernel supports don't do writes until they
726 So don't leave out the READ_ONCE().
811 is gone, and the barrier won't bring it back.  Therefore, if you are
1271 other loads, and so do the load in advance - even though they haven't actually
1276 It may turn out that the CPU didn't actually need the value - perhaps because a
1636      compiler that it doesn't know as much as it thinks it does:
1876      barrier after it.  It isn't guaranteed to insert anything more than a
1904      See Documentation/atomic_{t,bitops}.txt for more information.
2201 If it doesn't wake anything up then a memory barrier may or may not be
2331 But it won't see any of:
2452 On a UP system - where this wouldn't be a problem - the smp_mb() is just a
2463 some don't, but they're very heavily relied on as a group throughout the
2477 in that the carefully sequenced accesses in the driver code won't reach the
2530 Normally this won't be a problem because the I/O accesses done inside such
2778 A memory barrier isn't sufficient in such a case, but rather the cache must be
2805 assumption doesn't hold because: