On Tue, Jul 12, 2016 at 04:51:20AM -0700, Hugh Dickins wrote:
> The VM_BUG_ON_PAGE in page_move_anon_rmap() is more trouble than it's
> worth: the syzkaller fuzzer hit it again.  It's still wrong for some
> THP cases, because linear_page_index() was never intended to apply to
> addresses before the start of a vma.
> 
> That's easily fixed with a signed long cast inside linear_page_index();
> and Dmitry has tested such a patch, to verify the false positive.  But
> why extend linear_page_index() just for this case? when the avoidance
> in page_move_anon_rmap() has already grown ugly, and there's no reason
> for the check at all (nothing else there is using address or index).
> 
> Remove address arg from page_move_anon_rmap(), remove VM_BUG_ON_PAGE,
> remove CONFIG_DEBUG_VM PageTransHuge adjustment.
> 
> And one more thing: should the compound_head(page) be done inside or
> outside page_move_anon_rmap()?  It's usually pushed down to the lowest
> level nowadays (and mm/memory.c shows no other explicit use of it),
> so I think it's better done in page_move_anon_rmap() than by caller.

I agree, that's reasonable.

> Fixes: 0798d3c022dc ("mm: thp: avoid false positive VM_BUG_ON_PAGE in 
> page_move_anon_rmap()")
> Signed-off-by: Hugh Dickins <hu...@google.com>
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Cc: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
> Cc: Mika Westerberg <mika.westerb...@linux.intel.com>
> Cc: Andrea Arcangeli <aarca...@redhat.com>
> Cc: Rik van Riel <r...@redhat.com>
> Cc: sta...@vger.kernel.org # 4.5+

Acked-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com>

> ---
> Of course, we could just do a patch that deletes the VM_BUG_ON_PAGE
> (and CONFIG_DEBUG_VM PageTransHuge adjustment) for now, and the cleanup
> afterwards - but this doesn't affect a widely used interface, or go back
> many stable releases, so personally I prefer to do it all in one go.

+1.

-- 
 Kirill A. Shutemov

Reply via email to