On Tue, May 06, 2014 at 01:13:31AM +0300, Kirill A. Shutemov wrote: > It's critical for split_huge_page() (and migration) to catch and freeze > all PMDs on rmap walk. It gets tricky if there's concurrent fork() or > mremap() since usually we copy/move page table entries on dup_mm() or > move_page_tables() without rmap lock taken. To get it work we rely on > rmap walk order to not miss any entry. We expect to see destination VMA > after source one to work correctly. > > But after switching rmap implementation to interval tree it's not always > possible to preserve expected walk order.
Yeah, I think the actual bug was introduced in preparation of the interval tree, when the optimization of moving the target anon_vma to the tail of the chain was replaced by explicit locking again. That missed the THP case. > It works fine for dup_mm() since new VMA has the same vma_start_pgoff() > / vma_last_pgoff() and explicitly insert dst VMA after src one with > vma_interval_tree_insert_after(). > > But on move_vma() destination VMA can be merged into adjacent one and as > result shifted left in interval tree. Fortunately, we can detect the > situation and prevent race with rmap walk by moving page table entries > under rmap lock. See commit 38a76013ad80. > > Problem is that we miss the lock when we move transhuge PMD. Most likely > this bug caused the crash[1]. > > [1] http://thread.gmane.org/gmane.linux.kernel.mm/96473 > > Signed-off-by: Kirill A. Shutemov <[email protected]> > Cc: Andrea Arcangeli <[email protected]> > Cc: Rik van Riel <[email protected]> > Cc: Michel Lespinasse <[email protected]> > Cc: Dave Jones <[email protected]> > Cc: <[email protected]> [3.7+] > Signed-off-by: Kirill A. Shutemov <[email protected]> Fixes: 108d6642ad81 ("mm anon rmap: remove anon_vma_moveto_tail") Acked-by: Johannes Weiner <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
