+ corrections-to-memory-barrier-doc.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled

     Corrections to memory barrier doc

has been added to the -mm tree.  Its filename is

     corrections-to-memory-barrier-doc.patch

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

------------------------------------------------------
Subject: Corrections to memory barrier doc
From: David Howells <dhowells@xxxxxxxxxx>


Apply some small corrections to the memory barrier document, as contributed by:

	Christoph Lameter <clameter@xxxxxxx>
	Kirill Smelkov <kirr@xxxxxxxxxx>
	Randy Dunlap <rdunlap@xxxxxxxxxxxx>

Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---

 Documentation/memory-barriers.txt |   19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff -puN Documentation/memory-barriers.txt~corrections-to-memory-barrier-doc Documentation/memory-barriers.txt
--- a/Documentation/memory-barriers.txt~corrections-to-memory-barrier-doc
+++ a/Documentation/memory-barriers.txt
@@ -287,7 +287,7 @@ Memory barriers come in four basic varie
      A write barrier is a partial ordering on stores only; it is not required
      to have any effect on loads.
 
-     A CPU can be viewed as as commiting a sequence of store operations to the
+     A CPU can be viewed as committing a sequence of store operations to the
      memory system as time progresses.  All stores before a write barrier will
      occur in the sequence _before_ all the stores after the write barrier.
 
@@ -418,7 +418,7 @@ There are certain things that the Linux 
      indirect effect will be the order in which the second CPU sees the effects
      of the first CPU's accesses occur, but see the next point:
 
- (*) There is no guarantee that the a CPU will see the correct order of effects
+ (*) There is no guarantee that a CPU will see the correct order of effects
      from a second CPU's accesses, even _if_ the second CPU uses a memory
      barrier, unless the first CPU _also_ uses a matching memory barrier (see
      the subsection on "SMP Barrier Pairing").
@@ -489,7 +489,7 @@ lines.  The pointer P might be stored in
 variable B might be stored in an even-numbered cache line.  Then, if the
 even-numbered bank of the reading CPU's cache is extremely busy while the
 odd-numbered bank is idle, one can see the new value of the pointer P (&B),
-but the old value of the variable B (1).
+but the old value of the variable B (2).
 
 
 Another example of where data dependency barriers might by required is where a
@@ -749,7 +749,7 @@ some effectively random order, despite t
 	                                        :       :
 
 
-If, however, a read barrier were to be placed between the load of E and the
+If, however, a read barrier were to be placed between the load of B and the
 load of A on CPU 2:
 
 	CPU 1			CPU 2
@@ -1466,9 +1466,8 @@ instruction itself is complete.
 
 On a UP system - where this wouldn't be a problem - the smp_mb() is just a
 compiler barrier, thus making sure the compiler emits the instructions in the
-right order without actually intervening in the CPU.  Since there there's only
-one CPU, that CPU's dependency ordering logic will take care of everything
-else.
+right order without actually intervening in the CPU.  Since there's only one
+CPU, that CPU's dependency ordering logic will take care of everything else.
 
 
 ATOMIC OPERATIONS
@@ -1645,9 +1644,9 @@ functions:
 
      The PCI bus, amongst others, defines an I/O space concept - which on such
      CPUs as i386 and x86_64 cpus readily maps to the CPU's concept of I/O
-     space.  However, it may also mapped as a virtual I/O space in the CPU's
-     memory map, particularly on those CPUs that don't support alternate
-     I/O spaces.
+     space.  However, it may also be mapped as a virtual I/O space in the CPU's
+     memory map, particularly on those CPUs that don't support alternate I/O
+     spaces.
 
      Accesses to this space may be fully synchronous (as on i386), but
      intermediary bridges (such as the PCI host bridge) may not fully honour
_

Patches currently in -mm which might be from dhowells@xxxxxxxxxx are

selinux-add-hooks-for-key-subsystem.patch
keys-fix-race-between-two-instantiators-of-a-key.patch
git-nfs.patch
git-nfs-build-fixes.patch
nfs-build-fix-99.patch
add-page_mkwrite-vm_operations-method.patch
add-page_mkwrite-vm_operations-method-fix.patch
frv-__user-infrastructure.patch
frv-basic-__iomem-annotations.patch
frv-signal-annotations.patch
frv-sysctl-__user-annotations.patch
frv-binfmt_elf_fdpic-__user-annotations.patch
frv-misc-__user-annotations.patch
frv-misc-sparse-annotations.patch
frv-wrong-syscall.patch
ext2-xip-wont-build-without-mmu.patch
frv-initrd-is-grossly-broken-on-frv-never-built.patch
frv-null-noise-removal-in-frv-xchg.patch
frv-ieee1394-is-borken-on-frv.patch
frv-add-missing-qualifier-to-memcpy_fromio-prototype.patch
frv-trivial-cleanups-in-frv_ksymsc.patch
frv-clean-frv-unistdh.patch
fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
prepare-for-__copy_from_user_inatomic-to-not-zero-missed-bytes.patch
another-couple-of-alterations-to-the-memory-barrier-doc.patch
corrections-to-memory-barrier-doc.patch
net-rxrpc-use-list_move.patch
fs-use-list_move.patch
keys-sort-out-key-quota-system.patch
keys-discard-the-contents-of-a-key-on-revocation.patch
keys-let-keyctl_chown-change-a-keys-owner.patch
keys-allocate-key-serial-numbers-randomly.patch
keys-restrict-contents-of-proc-keys-to-viewable-keys.patch
keys-add-a-way-to-store-the-appropriate-context-for-newly-created-keys.patch
mutex-subsystem-synchro-test-module.patch

-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux