Commit ab09243aa95a ("mm/migrate.c: remove MIGRATE_PFN_LOCKED") changed
the way trylock_page() in migrate_vma_collect_pmd() works without
updating the comment. Reword the comment to be less misleading and a
better reflection of what happens.
Signed-off-by: Alistair Popple <apopple@xxxxxxxxxx>
Reported-by: Peter Xu <peterx@xxxxxxxxxx>
Fixes: ab09243aa95a ("mm/migrate.c: remove MIGRATE_PFN_LOCKED")
---
mm/migrate_device.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 5052093d0262..9e7ec925ec51 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -179,9 +179,16 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
get_page(page);
/*
- * Optimize for the common case where page is only mapped once
- * in one process. If we can lock the page, then we can safely
- * set up a special migration page table entry now.
+ * We rely on trylock_page() to avoid deadlock between
+ * concurrent migrations where each is waiting on the others
+ * page lock. If we can't immediately lock the page we fail this
+ * migration as it is only best effort anyway.
+ *
+ * If we can lock the page it's safe to set up a migration entry
+ * now. In the common case where the page is mapped once in a
+ * single process setting up the migration entry now is an
+ * optimisation to avoid walking the rmap later with
+ * try_to_migrate().
*/
if (trylock_page(page)) {
bool anon_exclusive;
--
2.35.1
