From: Andrea Arcangeli <aarcange@redhat.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
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>,
"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
Date: Thu, 28 Jan 2016 16:47:46 +0100 [thread overview]
Message-ID: <20160128154746.GI12228@redhat.com> (raw)
In-Reply-To: <CACT4Y+Z86=NoNPrS-vgtJiB54Akwq6FfAPf2wnBA1FX2BHafWQ@mail.gmail.com>
Hello,
On Wed, Jan 27, 2016 at 10:11:44PM +0100, Dmitry Vyukov wrote:
> Sorry, I meant only the second once. The mm bug.
> I guess you need at least CONFIG_DEBUG_VM. Run it in a tight parallel
> loop with CPU oversubscription (e.g. 32 parallel processes on 2 cores)
> for at least an hour.
Does this help for the mm bug?
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
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>,
"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
Date: Thu, 28 Jan 2016 16:47:46 +0100 [thread overview]
Message-ID: <20160128154746.GI12228@redhat.com> (raw)
In-Reply-To: <CACT4Y+Z86=NoNPrS-vgtJiB54Akwq6FfAPf2wnBA1FX2BHafWQ@mail.gmail.com>
Hello,
On Wed, Jan 27, 2016 at 10:11:44PM +0100, Dmitry Vyukov wrote:
> Sorry, I meant only the second once. The mm bug.
> I guess you need at least CONFIG_DEBUG_VM. Run it in a tight parallel
> loop with CPU oversubscription (e.g. 32 parallel processes on 2 cores)
> for at least an hour.
Does this help for the mm bug?
>From 0cc410ae59800444ca929e3dc48e4f1580a95be6 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Thu, 28 Jan 2016 16:34:44 +0100
Subject: [PATCH 1/1] mm: validate_mm browse_rb SMP race condition
The mmap_sem for reading in validate_mm called from expand_stack is
not enough to prevent the argumented rbtree rb_subtree_gap information
to change from under us because expand_stack may be running from other
threads concurrently which will hold the mmap_sem for reading too.
The argumented rbtree is updated with vma_gap_update under the
page_table_lock so use it in browse_rb() too to avoid false positives.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
mm/mmap.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index f384def..8389e03 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -389,8 +389,9 @@ static long vma_compute_subtree_gap(struct vm_area_struct *vma)
}
#ifdef CONFIG_DEBUG_VM_RB
-static int browse_rb(struct rb_root *root)
+static int browse_rb(struct mm_struct *mm)
{
+ struct rb_root *root = &mm->mm_rb;
int i = 0, j, bug = 0;
struct rb_node *nd, *pn = NULL;
unsigned long prev = 0, pend = 0;
@@ -413,12 +414,14 @@ static int browse_rb(struct rb_root *root)
vma->vm_start, vma->vm_end);
bug = 1;
}
+ spin_lock(&mm->page_table_lock);
if (vma->rb_subtree_gap != vma_compute_subtree_gap(vma)) {
pr_emerg("free gap %lx, correct %lx\n",
vma->rb_subtree_gap,
vma_compute_subtree_gap(vma));
bug = 1;
}
+ spin_unlock(&mm->page_table_lock);
i++;
pn = nd;
prev = vma->vm_start;
@@ -474,7 +477,7 @@ static void validate_mm(struct mm_struct *mm)
mm->highest_vm_end, highest_address);
bug = 1;
}
- i = browse_rb(&mm->mm_rb);
+ i = browse_rb(mm);
if (i != mm->map_count) {
if (i != -1)
pr_emerg("map_count %d rb %d\n", mm->map_count, i);
next prev parent reply other threads:[~2016-01-28 15:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 10:51 mm: BUG in expand_downwards Dmitry Vyukov
2016-01-27 10:51 ` Dmitry Vyukov
2016-01-27 11:49 ` Konstantin Khlebnikov
2016-01-27 11:49 ` Konstantin Khlebnikov
2016-01-27 12:24 ` Dmitry Vyukov
2016-01-27 12:24 ` Dmitry Vyukov
2016-01-27 14:42 ` Dmitry Vyukov
2016-01-27 14:42 ` Dmitry Vyukov
2016-01-27 19:41 ` Oleg Nesterov
2016-01-27 19:41 ` Oleg Nesterov
2016-01-27 21:11 ` Dmitry Vyukov
2016-01-27 21:11 ` Dmitry Vyukov
2016-01-28 15:47 ` Andrea Arcangeli [this message]
2016-01-28 15:47 ` Andrea Arcangeli
2016-01-29 10:39 ` Dmitry Vyukov
2016-01-29 10:39 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160128154746.GI12228@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=gang.chen.5i5j@gmail.com \
--cc=glider@google.com \
--cc=hughd@google.com \
--cc=kcc@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=koct9i@gmail.com \
--cc=kwapulinski.piotr@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=oleg@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.