mm/migrate_device.c: fix a misleading and outdated comment

Commit ab09243aa9 ("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.

Link: https://lkml.kernel.org/r/20220830020138.497063-1-apopple@nvidia.com
Fixes: ab09243aa9 ("mm/migrate.c: remove MIGRATE_PFN_LOCKED")
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reported-by: Peter Xu <peterx@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This commit is contained in:
Alistair Popple 2022-08-30 12:01:38 +10:00 committed by Andrew Morton
parent 663d0cfd2e
commit 0742e49026

View File

@ -185,9 +185,16 @@ again:
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;