On Mon, 5 May 2008, Nick Piggin wrote: > Index: linux-2.6/mm/memory.c > =================================================================== > --- linux-2.6.orig/mm/memory.c > +++ linux-2.6/mm/memory.c > @@ -311,6 +311,37 @@ int __pte_alloc(struct mm_struct *mm, pm > if (!new) > return -ENOMEM; > > + /* > + * Ensure all pte setup (eg. pte page lock and page clearing) are > + * visible before the pte is made visible to other CPUs by being > + * put into page tables. > + * > + * The other side of the story is the pointer chasing in the page > + * table walking code (when walking the page table without locking; > + * ie. most of the time). Fortunately, these data accesses consist > + * of a chain of data-dependent loads, meaning most CPUs (alpha > + * being the notable exception) will already guarantee loads are > + * seen in-order. x86 has a "reference" implementation of > + * smp_read_barrier_depends() barriers in its page table walking > + * code, even though that barrier is a simple noop on that architecture. > + * Alpha obviously also has the required barriers. > + * > + * It is debatable whether or not the smp_read_barrier_depends() > + * barriers are required for kernel page tables; it could be that > + * nowhere in the kernel do we walk those pagetables without taking > + * init_mm's page_table_lock. Just delete "; it could be that ... init_mm's page_table_lock": in general (if not everywhere) the architectures do not nowadays take init_mm's page_table_lock to walk down those pagetables (blame me for removing it, if anyone thinks that was wrong: I stand by it). Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
