On Mon, May 05, 2008 at 05:57:20PM +0100, Hugh Dickins wrote: > 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). OK. That's fine IMO and I'll remove that line. -- 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
