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(-)
