X-Git-Url: http://pilppa.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=Documentation%2Fmemory-barriers.txt;h=f5b7127f54acb6af1d9f997a40e099b60c0b7571;hb=be821b78af9de886571e3565515a59f966d66f42;hp=4e17beba237902908b33d38b764c285fec433724;hpb=1212663fba7c5e003e05d24f043d5ed57eb18b24;p=linux-2.6-omap-h63xx.git

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 4e17beba237..f5b7127f54a 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -430,8 +430,8 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
 
 	[*] For information on bus mastering DMA and coherency please read:
 
-	    Documentation/pci.txt
-	    Documentation/DMA-mapping.txt
+	    Documentation/PCI/pci.txt
+	    Documentation/PCI/PCI-DMA-mapping.txt
 	    Documentation/DMA-API.txt
 
 
@@ -994,7 +994,17 @@ The Linux kernel has eight basic CPU memory barriers:
 	DATA DEPENDENCY	read_barrier_depends()	smp_read_barrier_depends()
 
 
-All CPU memory barriers unconditionally imply compiler barriers.
+All memory barriers except the data dependency barriers imply a compiler
+barrier. Data dependencies do not impose any additional compiler ordering.
+
+Aside: In the case of data dependencies, the compiler would be expected to
+issue the loads in the correct order (eg. `a[b]` would have to load the value
+of b before loading a[b]), however there is no guarantee in the C specification
+that the compiler may not speculate the value of b (eg. is equal to 1) and load
+a before b (eg. tmp = a[1]; if (b != 1) tmp = a[b]; ). There is also the
+problem of a compiler reloading b after having loaded a[b], thus having a newer
+copy of b than a[b]. A consensus has not yet been reached about these problems,
+however the ACCESS_ONCE macro is a good place to start looking.
 
 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
 systems because it is assumed that a CPU will appear to be self-consistent,
@@ -1493,7 +1503,7 @@ explicit lock operations, described later).  These include:
 	atomic_dec_and_test();
 	atomic_sub_and_test();
 	atomic_add_negative();
-	atomic_add_unless();
+	atomic_add_unless();	/* when succeeds (returns 1) */
 	test_and_set_bit();
 	test_and_clear_bit();
 	test_and_change_bit();