On Tue, 27 Apr 2010 22:30:52 +0100 Mel Gorman <mel@xxxxxxxxx> wrote: > During exec(), a temporary stack is setup and moved later to its final > location. There is a race between migration and exec whereby a migration > PTE can be placed in the temporary stack. When this VMA is moved under the > lock, migration no longer knows where the PTE is, fails to remove the PTE > and the migration PTE gets copied to the new location. This later causes > a bug when the migration PTE is discovered but the page is not locked. > > This patch handles the situation by removing the migration PTE when page > tables are being moved in case migration fails to find them. The alternative > would require significant modification to vma_adjust() and the locks taken > to ensure a VMA move and page table copy is atomic with respect to migration. > > Signed-off-by: Mel Gorman <mel@xxxxxxxxx> Mel, I don't like this fix. Consider following, 1. try_to_unmap(oldpage) 2. copy and replace 3. remove_migration_ptes(oldpage, newpage) What this patch handles is "3: remove_migration_ptes fails to remap it and migration_pte will remain there case....The fact "new page is not mapped" means "get_page() is not called against the new page". So, the new page have been able to be freed until we restart move_ptes. I bet calling __get_user_pages_fast() before vma_adjust() is the way to go. When page_count(page) != page_mapcount(page) +1, migration skip it. Thanks, -Kame -- 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>