Ok I had a first look: On Tue, Apr 27, 2010 at 10:30:50PM +0100, Mel Gorman wrote: > CPUA CPU B > do_fork() > copy_mm() (from process 1 to process2) > insert new vma to mmap_list (if inode/anon_vma) Insert to the tail of the anon_vma list... > pte_lock(process1) > unmap a page > insert migration_entry > pte_unlock(process1) > > migrate page copy > copy_page_range > remap new page by rmap_walk() rmap_walk will walk process1 first! It's at the head, the vmas with unmapped ptes are at the tail so process1 is walked before process2. > pte_lock(process2) > found no pte. > pte_unlock(process2) > pte lock(process2) > pte lock(process1) > copy migration entry to process2 > pte unlock(process1) > pte unlokc(process2) > pte_lock(process1) > replace migration entry > to new page's pte. > pte_unlock(process1) rmap_walk has to lock down process1 before process2, this is the ordering issue I already mentioned in earlier email. So it cannot happen and this patch is unnecessary. The ordering is fundamental and as said anon_vma_link already adds new vmas to the _tail_ of the anon-vma. And this is why it has to add to the tail. If anon_vma_link would add new vmas to the head of the list, the above bug could materialize, but it doesn't so it cannot happen. In mainline anon_vma_link is called anon_vma_chain_link, see the list_add_tail there to provide this guarantee. Because process1 is walked first by CPU A, the migration entry is replaced by the final pte before copy-migration-entry runs. Alternatively if copy-migration-entry runs before before process1 is walked, the migration entry will be copied and found in process 2. Comments welcome. Andrea -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>