From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>, Eric Whitney <eric.whitney@hp.com>
Subject: Re: Interesting Bug in page migration via mbind()
Date: Thu, 01 Nov 2007 12:46:24 -0400 [thread overview]
Message-ID: <1193935584.5300.68.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0710311406570.22599@schroedinger.engr.sgi.com>
On Wed, 2007-10-31 at 14:07 -0700, Christoph Lameter wrote:
> On Wed, 31 Oct 2007, Lee Schermerhorn wrote:
>
> > How to address?
>
> Looks like we are not updating the vma information correctly when
> splitting vmas?
Update: error path is [NOT try_to_unmap()...]:
do_mbind()->migrate_pages()->unmap_and_move()=>new_vma_page()
->page_address_in_vma()->vma_address()
do_mbind() passes the first vma of the range to migrate_pages() via the
'void * private' argument. This vma is passed to page_address_in_vma().
However, the pages in the page list to be migrated can come from
multiple vmas.
I have an idea for a patch:
We need to pass a valid vma--i.e., one that actually maps the page--to
vma_address(). In new_vma_page(), fetch page_address_in_vma(). If
returns EFAULT, "find the vma that maps page". How? Couple of
options:
1) start by assuming that it's a later vma in the vm_next list--probably
the very next one--and try subsequent vmas in a loop. It may not be the
very next vma if none of the pages in that vma are migratable. But,
this method should work.
2) call into rmap.c--some new function?--to look up vma based on page's
index--the way try_to_unmap_file() does. Sounds heavier weight to me,
so I'll start with option 1 and see what it looks like.
Will send shortly, if I get to it today. Else, after the weekend.
Later,
Lee
--
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>
prev parent reply other threads:[~2007-11-01 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 20:45 Interesting Bug in page migration via mbind() Lee Schermerhorn
2007-10-31 21:07 ` Christoph Lameter
2007-10-31 21:16 ` Lee Schermerhorn
2007-11-01 16:46 ` Lee Schermerhorn [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=1193935584.5300.68.camel@localhost \
--to=lee.schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=eric.whitney@hp.com \
--cc=linux-mm@kvack.org \
/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.