Revision 3ad33b2436b545cbe8b28e53f3710432cad457ab authored by Lee Schermerhorn on 15 November 2007, 00:59:10 UTC, committed by Linus Torvalds on 15 November 2007, 02:45:38 UTC
We hit the BUG_ON() in mm/rmap.c:vma_address() when trying to migrate via
mbind(MPOL_MF_MOVE) a non-anon region that spans multiple vmas.  For
anon-regions, we just fail to migrate any pages beyond the 1st vma in the
range.

This occurs because do_mbind() collects a list of pages to migrate by
calling check_range().  check_range() walks the task's mm, spanning vmas as
necessary, to collect the migratable pages into a list.  Then, do_mbind()
calls migrate_pages() passing the list of pages, a function to allocate new
pages based on vma policy [new_vma_page()], and a pointer to the first vma
of the range.

For each page in the list, new_vma_page() calls page_address_in_vma()
passing the page and the vma [first in range] to obtain the address to get
for alloc_page_vma().  The page address is needed to get interleaving
policy correct.  If the pages in the list come from multiple vmas,
eventually, new_page_address() will pass that page to page_address_in_vma()
with the incorrect vma.  For !PageAnon pages, this will result in a bug
check in rmap.c:vma_address().  For anon pages, vma_address() will just
return EFAULT and fail the migration.

This patch modifies new_vma_page() to check the return value from
page_address_in_vma().  If the return value is EFAULT, new_vma_page()
searchs forward via vm_next for the vma that maps the page--i.e., that does
not return EFAULT.  This assumes that the pages in the list handed to
migrate_pages() is in address order.  This is currently case.  The patch
documents this assumption in a new comment block for new_vma_page().

If new_vma_page() cannot locate the vma mapping the page in a forward
search in the mm, it will pass a NULL vma to alloc_page_vma().  This will
result in the allocation using the task policy, if any, else system default
policy.  This situation is unlikely, but the patch documents this behavior
with a comment.

Note, this patch results in restarting from the first vma in a multi-vma
range each time new_vma_page() is called.  If this is not acceptable, we
can make the vma argument a pointer, both in new_vma_page() and it's caller
unmap_and_move() so that the value held by the loop in migrate_pages()
always passes down the last vma in which a page was found.  This will
require changes to all new_page_t functions passed to migrate_pages().  Is
this necessary?

For this patch to work, we can't bug check in vma_address() for pages
outside the argument vma.  This patch removes the BUG_ON().  All other
callers [besides new_vma_page()] already check the return status.

Tested on x86_64, 4 node NUMA platform.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent e1a1c99
History
File Mode Size
platform
acconfig.h -rw-r--r-- 7.2 KB
acdebug.h -rw-r--r-- 6.5 KB
acdisasm.h -rw-r--r-- 12.9 KB
acdispat.h -rw-r--r-- 10.8 KB
acevents.h -rw-r--r-- 6.5 KB
acexcep.h -rw-r--r-- 13.0 KB
acglobal.h -rw-r--r-- 13.5 KB
achware.h -rw-r--r-- 4.2 KB
acinterp.h -rw-r--r-- 15.9 KB
aclocal.h -rw-r--r-- 31.2 KB
acmacros.h -rw-r--r-- 27.6 KB
acnames.h -rw-r--r-- 3.4 KB
acnamesp.h -rw-r--r-- 9.2 KB
acobject.h -rw-r--r-- 15.3 KB
acopcode.h -rw-r--r-- 21.8 KB
acoutput.h -rw-r--r-- 8.0 KB
acparser.h -rw-r--r-- 7.2 KB
acpi.h -rw-r--r-- 3.1 KB
acpi_bus.h -rw-r--r-- 10.4 KB
acpi_drivers.h -rw-r--r-- 5.3 KB
acpi_numa.h -rw-r--r-- 522 bytes
acpiosxf.h -rw-r--r-- 7.8 KB
acpixf.h -rw-r--r-- 9.6 KB
acresrc.h -rw-r--r-- 10.8 KB
acstruct.h -rw-r--r-- 7.6 KB
actables.h -rw-r--r-- 4.0 KB
actbl.h -rw-r--r-- 14.1 KB
actbl1.h -rw-r--r-- 19.9 KB
actypes.h -rw-r--r-- 35.7 KB
acutils.h -rw-r--r-- 16.8 KB
amlcode.h -rw-r--r-- 18.5 KB
amlresrc.h -rw-r--r-- 9.7 KB
container.h -rw-r--r-- 198 bytes
pdc_intel.h -rw-r--r-- 935 bytes
processor.h -rw-r--r-- 8.5 KB

back to top