linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Hugh Dickins <hughd@google.com>,
	Christoph Lameter <cl@gentwo.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: kernel BUG at /src/linux-dev/mm/mempolicy.c:1738! on v3.16-rc1
Date: Fri, 20 Jun 2014 14:42:25 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LSU.2.11.1406201438590.8689@eggly.anvils> (raw)
In-Reply-To: <20140620211253.GC15620@nhori.bos.redhat.com>

On Fri, 20 Jun 2014, Naoya Horiguchi wrote:
> On Fri, Jun 20, 2014 at 01:03:58PM -0700, Hugh Dickins wrote:
> > On Fri, 20 Jun 2014, Naoya Horiguchi wrote:
> > > On Fri, Jun 20, 2014 at 09:24:36AM -0500, Christoph Lameter wrote:
> > > > On Thu, 19 Jun 2014, Naoya Horiguchi wrote:
> > > >
> > > > > I'm suspecting that mbind_range() do something wrong around vma handling,
> > > > > but I don't have enough luck yet. Anyone has an idea?
> > > >
> > > > Well memory policy data corrupted. This looks like you were trying to do
> > > > page migration via mbind()?
> > > 
> > > Right.
> > > 
> > > > Could we get some more details as to what is
> > > > going on here? Specifically the parameters passed to mbind would be
> > > > interesting.
> > > 
> > > My view about the kernel behavior was in another email a few hours ago.
> > > And as for what userspace did, I attach the reproducer below. It's simply
> > > doing mbind(mode=MPOL_BIND, flags=MPOL_MF_MOVE_ALL) on random address/length/node.
> > 
> > Thanks for the additional information earlier.  ext4, so no shmem
> > shared mempolicy involved: that cuts down the bugspace considerably.
> > 
> > I agree from what you said that it looked like corrupt vm_area_struct
> > and hence corrupt policy.
> > 
> > Here's an obvious patch to try, entirely untested - thanks for the
> > reproducer, but I'd rather leave the testing to you.  Sounds like
> > you have a useful fuzzer there: good catch.
> > 
> > 
> > [PATCH] mm: fix crashes from mbind() merging vmas
> > 
> > v2.6.34's 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced
> > vma merging to mbind(), but it should have also changed the convention
> > of passing start vma from queue_pages_range() (formerly check_range())
> > to new_vma_page(): vma merging may have already freed that structure,
> > resulting in BUG at mm/mempolicy.c:1738 and probably worse crashes.
> > 
> > Fixes: 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
> > Reported-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > Cc: stable@vger.kernel.org # 2.6.34+
> 
> With your patch, the bug doesn't reproduce in one hour testing. I think
> it's long enough because it took only a few minutes until the reproducer
> triggered the bug without your patch.
> So I think the problem was gone, thank you very much!
> 
> Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
& Acked-by: Christoph Lameter <cl@linux.com>

Great, thank you both.  I was afraid you might hit something else
immediately.  I'll send the patch to Andrew later - unless it
magically appears in his tree before.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2014-06-20 21:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 21:56 kernel BUG at /src/linux-dev/mm/mempolicy.c:1738! on v3.16-rc1 Naoya Horiguchi
2014-06-20  4:35 ` Hugh Dickins
2014-06-20 15:40   ` Naoya Horiguchi
2014-06-20 14:24 ` Christoph Lameter
2014-06-20 19:46   ` Naoya Horiguchi
2014-06-20 20:03     ` Hugh Dickins
2014-06-20 20:32       ` Christoph Lameter
2014-06-20 21:12       ` Naoya Horiguchi
2014-06-20 21:42         ` Hugh Dickins [this message]

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=alpine.LSU.2.11.1406201438590.8689@eggly.anvils \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=nao.horiguchi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).