On 11/19/18 3:10 PM, Michal Hocko wrote: > On Mon 19-11-18 13:51:21, Michal Hocko wrote: >> On Mon 19-11-18 13:40:33, Michal Hocko wrote: >>> How are >>> we supposed to converge when the swapin code waits for the migration to >>> finish with the reference count elevated?
Indeed this looks wrong. How comes we only found this out now? I guess the race window where refcounts matter is only a part of the whole migration, where we update the mapping (migrate_page_move_mapping()). That's before copying contents, flags etc. >> Just to clarify. This is not only about swapin obviously. Any caller of >> __migration_entry_wait is affected the same way AFAICS. > > In other words. Why cannot we do the following? > > diff --git a/mm/migrate.c b/mm/migrate.c > index f7e4bfdc13b7..7ccab29bcf9a 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -324,19 +324,9 @@ void __migration_entry_wait(struct mm_struct *mm, pte_t > *ptep, > goto out; > > page = migration_entry_to_page(entry); > - > - /* > - * Once page cache replacement of page migration started, page_count > - * *must* be zero. And, we don't want to call wait_on_page_locked() > - * against a page without get_page(). > - * So, we use get_page_unless_zero(), here. Even failed, page fault > - * will occur again. > - */ > - if (!get_page_unless_zero(page)) > - goto out; > pte_unmap_unlock(ptep, ptl); > - wait_on_page_locked(page); > - put_page(page); > + page_lock(page); > + page_unlock(page); So what protects us from locking a page whose refcount dropped to zero? and is being freed? The checks in freeing path won't be happy about a stray lock. I suspect it's not that simple to fix this. Perhaps migration code could set some flag/bit in the page during the part where it stabilizes refcounts, and __migration_entry_wait() would just spin until the bit is cleared, and only then proceed with the current get_page+wait? Or we could maybe wait on the pte itself and not page? > return; > out: > pte_unmap_unlock(ptep, ptl); >
