For the migration of PAGE_SIZE pages, we can choose to continue to do
migration with "force" switch even if the old page has page lock held.
But for hugepage, I/O of subpages are not necessarily completed
in ascending order, which can cause race.
So we make migration fail then for safety.
Signed-off-by: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
---
mm/migrate.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 7f9a37c..43347e1 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -820,11 +820,14 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
rc = -EAGAIN;
- if (!trylock_page(hpage)) {
- if (!force)
- goto out;
- lock_page(hpage);
- }
+ /*
+ * If some subpages are locked, it can cause race condition.
+ * So then we return from migration and try again.
+ */
+ if (!trylock_huge_page(hpage))
+ goto out;
+
+ wait_on_huge_page_writeback(hpage);
if (PageAnon(hpage)) {
rcu_read_lock();
@@ -855,7 +858,7 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
if (rcu_locked)
rcu_read_unlock();
out:
- unlock_page(hpage);
+ unlock_huge_page(hpage);
if (rc != -EAGAIN)
put_page(hpage);
--
1.7.2.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>