From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S966904AbcA0Tln (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jan 2016 14:41:43 -0500
Received: from mx1.redhat.com ([209.132.183.28]:35223 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S966134AbcA0Tlh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jan 2016 14:41:37 -0500
Date: Wed, 27 Jan 2016 20:41:32 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Chen Gang <gang.chen.5i5j@gmail.com>, Michal Hocko <mhocko@suse.com>,
        Piotr Kwapulinski <kwapulinski.piotr@gmail.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, Hugh Dickins <hughd@google.com>,
        Sasha Levin <sasha.levin@oracle.com>,
        syzkaller <syzkaller@googlegroups.com>,
        Kostya Serebryany <kcc@google.com>,
        Alexander Potapenko <glider@google.com>
Subject: Re: mm: BUG in expand_downwards
Message-ID: <20160127194132.GA896@redhat.com>
References: <CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.com>
 <CALYGNiP6-T=LuBwzKys7TPpFAiGC-U7FymDT4kr3Zrcfo7CoiQ@mail.gmail.com>
 <CACT4Y+YNUZumEy2-OXhDku3rdn-4u28kCDRKtgYaO2uA9cYv5w@mail.gmail.com>
 <CACT4Y+afp8BaUvQ72h7RzQuMOX05iDEyP3p3wuZfjaKcW_Ud9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+afp8BaUvQ72h7RzQuMOX05iDEyP3p3wuZfjaKcW_Ud9A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/27, Dmitry Vyukov wrote:
>
> On Wed, Jan 27, 2016 at 1:24 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Wed, Jan 27, 2016 at 12:49 PM, Konstantin Khlebnikov
> > <koct9i@gmail.com> wrote:
> >> It seems anon_vma appeared between lock and unlock.
> >>
> >> This should fix the bug and make code faster (write lock isn't required here)
> >>
> >> --- a/mm/mmap.c
> >> +++ b/mm/mmap.c
> >> @@ -453,12 +453,16 @@ static void validate_mm(struct mm_struct *mm)
> >>         struct vm_area_struct *vma = mm->mmap;
> >>
> >>         while (vma) {
> >> +               struct anon_vma *anon_vma = vma->anon_vma;
> >>                 struct anon_vma_chain *avc;
> >>
> >> -               vma_lock_anon_vma(vma);
> >> -               list_for_each_entry(avc, &vma->anon_vma_chain, same_vma)
> >> -                       anon_vma_interval_tree_verify(avc);
> >> -               vma_unlock_anon_vma(vma);
> >> +               if (anon_vma) {
> >> +                       anon_vma_lock_read(anon_vma);
> >> +                       list_for_each_entry(avc, &vma->anon_vma_chain, same_vma)
> >> +                               anon_vma_interval_tree_verify(avc);
> >> +                       anon_vma_unlock_read(anon_vma);
> >> +               }
> >> +
> >>                 highest_address = vma->vm_end;
> >>                 vma = vma->vm_next;
> >>                 i++;
> >
> >
> > Now testing with this patch. Thanks for quick fix!
>
>
> Hit the same BUG with this patch.

Do you mean the same "bad unlock balance detected" BUG? this should be "obviously"
fixed by the patch above...

Or you mean the 2nd VM_BUG_ON_MM() ?

> Please try to reproduce it locally and test.

tried to reproduce, doesn't work.

Oleg.