migrate_misplaced_transhuge_page race conditions

Aaron found a new instance of the THP MADV_DONTNEED race against pmdp_clear_flush* variants, that was apparently left unfixed.

While looking into the race found by Aaron, I may have found two more issues in migrate_misplaced_transhuge_page.

These race conditions would not cause kernel instability, but they'd corrupt userland data or leave data non zero after MADV_DONTNEED.

I did only minor testing, and I don't expect to be able to reproduce this (especially the lack of ->invalidate_range before migrate_page_copy, requires the latest iommu hardware or infiniband to reproduce). The last patch is noop for x86 and it needs further review from maintainers of archs that implement flush_cache_range() (not in CC yet).

To avoid confusion, it's not the first patch that introduces the bug fixed in the second patch, even before removing the pmdp_huge_clear_flush_notify, that _notify suffix was called after migrate_page_copy already run.

Andrea Arcangeli (3):
mm: thp: fix MADV_DONTNEED vs migrate_misplaced_transhuge_page race
condition
mm: thp: fix mmu_notifier in migrate_misplaced_transhuge_page()
mm: thp: relocate flush_cache_range() in
migrate_misplaced_transhuge_page()

 mm/huge_memory.c | 14 +++++++++++++-
 mm/migrate.c     | 43 ++++++++++++++++++++++++-------------------
 2 files changed, 37 insertions(+), 20 deletions(-)