Re: [PATCH] mm/rmap: fix BUG at rmap_walk

[Dave Jones]

On Wed, Dec 18, 2013 at 04:50:49PM -0800, Andrew Morton wrote:
 > On Wed, 18 Dec 2013 19:41:44 -0500 Sasha Levin <sasha.levin@xxxxxxxxxx> wrote:
 > 
 > > On 12/18/2013 07:28 PM, Andrew Morton wrote:
 > > > On Thu, 19 Dec 2013 08:16:35 +0800 Wanpeng Li <liwanp@xxxxxxxxxxxxxxxxxx> wrote:
 > > >
 > > >> page_get_anon_vma() called in page_referenced_anon() will lock and
 > > >> increase the refcount of anon_vma, page won't be locked for anonymous
 > > >> page. This patch fix it by skip check anonymous page locked.
 > > >>
 > > >> [  588.698828] kernel BUG at mm/rmap.c:1663!
 > > >
 > > > Why is all this suddenly happening.  Did we change something, or did a
 > > > new test get added to trinity?
 > > 
 > > Dave has improved mmap testing in trinity, maybe it's related?
 > 
 > Dave, can you please summarise recent trinity changes for us?

In the past, the only mmaps we did were created on startup by the initial process,
and were then inherited by the child processes when they fork()'d.

After the recent changes, that's still true, but in addition, we now have
some smarts so that when a child does a random mmap() call, if it succeeds,
we store the result in a per-child list for re-use in subsequent syscalls by
that same child process.

Another reason that a lot of hugepage stuff seems to be falling out is that
trinity didn't do big mmaps before, because after a few children forked
and the maps got touched, we'd run into oom's pretty quickly.
Now that we have per-child mmapping, sometimes it successfully does a hugepage map.

http://git.codemonkey.org.uk/?p=trinity.git;a=blob_plain;f=syscalls/mmap.c;hb=HEAD
is the code that's generating the random map arguments. It should be pretty obvious,
but holler if there's something that needs explaining.

dirty_mapping() is here http://git.codemonkey.org.uk/?p=trinity.git;a=blob_plain;f=maps.c;hb=HEAD

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/