mm: memory migration: bug in touch_unmapped_address
Subsystems (2)
PATCH 1/1 mm: memory migration: bug in touch_unmapped_address
Hirokazu,
The length field in the call to get_user_pages() from touch_unmapped_pages() is incorrectly specified in bytes, not pages.
As a result of this, if you use the migration code to migrate a page, then subsequent pages (that are not necessarily currently allocated or mapped) can be allocated and mapped as a result of the migration call.
[touch_unmapped_pages() is added by the memory migration code from the memory hotplug patch so this is not currently part of the mainline kernel]
See attached patch for the fix.
Signature · 9 lines
Best Regards,
Ray
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[email protected] [email protected]
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------The "len" parameter (4th arg) of get_user_pages() is in pages, not bytes. The effect of this bug is that if you migrate a page, and if this page is followed by valid virtual addresses, but these pages have not yet been touched and allocated, then the migration call will cause those pages to be touched and allocated. The number of pages so effected is the min of (16384, the remaining number of pages in the vma, the number of pages required to fill out the current pmd).
mm/rmap.c +1 -2
@@ -554,8 +554,7 @@ touch_unmapped_address(struct list_head vma =find_vma (v1->mm, v1->addr);if (vma ==NULL ) goto out; - error =get_user_pages (current, v1->mm, v1->addr,PAGE_SIZE , -0 ,0 ,NULL ,NULL ); + error =get_user_pages (current, v1->mm, v1->addr,1 ,0 ,0 ,NULL ,NULL );if (error <0 ) ret = error; out:
Good catch.
That was the reason for the migration cache problems you were seeing?
Quoted 41 lines · Ray Bryant
Hirokazu,
The length field in the call to
get_user_pages()fromtouch_unmapped_pages()is incorrectly specified in bytes, not pages.As a result of this, if you use the migration code to migrate a page, then subsequent pages (that are not necessarily currently allocated or mapped) can be allocated and mapped as a result of the migration call.
[
touch_unmapped_pages()is added by the memory migration code from the memory
hotplug patch so this is not currently part of the mainline kernel]See attached patch for the fix.
Signature · 23 lines
Best Regards, Ray ----------------------------------------------- Ray Bryant 512-453-9679 (work) 512-507-7807 (cell) [email protected] [email protected] The box said: "Requires Windows 98 or better", so I installed Linux. ----------------------------------------------- The "len" parameter (4th arg) of get_user_pages() is in pages, not bytes. The effect of this bug is that if you migrate a page, and if this page is followed by valid virtual addresses, but these pages have not yet been touched and allocated, then the migration call will cause those pages to be touched and allocated. The number of pages so effected is the min of (16384, the remaining number of pages in the vma, the number of pages required to fill out the current pmd). Signed-off-by: Ray Bryant <[email protected]> Index: linux/mm/rmap.c ===================================================================
mm/rmap.c touch_unmapped_address(struct list_head · line 560
Quoted 9 lines
mm/rmap.c +1
-2@@ -554,8 +554,7 @@ touch_unmapped_address(struct list_head vma =find_vma (v1->mm, v1->addr);if (vma ==NULL ) goto out; - error =get_user_pages (current, v1->mm, v1->addr,PAGE_SIZE , -0 ,0 ,NULL ,NULL ); + error =get_user_pages (current, v1->mm, v1->addr,1 ,0 ,0 ,NULL ,NULL );if (error <0 ) ret = error; out:
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 4 lines · Marcelo Tosatti
Good catch.
That was the reason for the migration cache problems you were seeing?
AFAIK, no. I found this problem because pages were being touched after I scanned for pages to be migrated -- the result was that pages that had not been touched by the application were being touched and then left on the old nodes.
For the moment, I'm still pursuing a strategy of getting my manual page migration code to work without the migration cache -- once I've got that all working I'll come back and revisit the migration cache bug I had reported.
Signature · 14 lines
Best Regards,
Ray
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[email protected] [email protected]
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>Hi Ray,
Quoted 8 lines
Hirokazu,
The length field in the call to
get_user_pages()fromtouch_unmapped_pages()is incorrectly specified in bytes, not pages.As a result of this, if you use the migration code to migrate a page, then subsequent pages (that are not necessarily currently allocated or mapped) can be allocated and mapped as a result of the migration call.
Yes, you're absolutely right.
I'll fix it soon.
Quoted 4 lines
[
touch_unmapped_pages()is added by the memory migration code from the memory hotplug patch so this is not currently part of the mainline kernel]See attached patch for the fix.
Thank you,
Hirokazu Takahashi
who is the person looking for new sponsors to help us to continue developing the memory migration feature.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>