From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753719AbcGLMF5 (ORCPT ); Tue, 12 Jul 2016 08:05:57 -0400 Received: from mail-lf0-f52.google.com ([209.85.215.52]:35782 "EHLO mail-lf0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbcGLMF4 (ORCPT ); Tue, 12 Jul 2016 08:05:56 -0400 Date: Tue, 12 Jul 2016 15:05:51 +0300 From: "Kirill A. Shutemov" To: Hugh Dickins Cc: Andrew Morton , Dmitry Vyukov , "Kirill A. Shutemov" , Andrea Arcangeli , Rik van Riel , Mika Westerberg , "linux-mm@kvack.org" , Vlastimil Babka , LKML , Andrey Ryabinin , Konstantin Khlebnikov , Greg Thelen , Suleiman Souhlal , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin Subject: Re: [PATCH] mm: thp: refix false positive BUG in page_move_anon_rmap() Message-ID: <20160712120551.GB18041@node> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Reported-by: Dmitry Vyukov > Cc: Kirill A. Shutemov > Cc: Mika Westerberg > Cc: Andrea Arcangeli > Cc: Rik van Riel > Cc: stable@vger.kernel.org # 4.5+ Acked-by: Kirill A. Shutemov > --- > 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