From: Andrea Arcangeli <aarcange@redhat.com>
To: linux-mm@kvack.org
Cc: Aaron Tomlin <atomlin@redhat.com>, Mel Gorman <mgorman@suse.de>,
Jerome Glisse <jglisse@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 0/3] migrate_misplaced_transhuge_page race conditions
Date: Fri, 12 Oct 2018 20:24:27 -0400 [thread overview]
Message-ID: <20181013002430.698-1-aarcange@redhat.com> (raw)
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(-)
next reply other threads:[~2018-10-13 0:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 0:24 Andrea Arcangeli [this message]
2018-10-13 0:24 ` [PATCH 1/3] mm: thp: fix MADV_DONTNEED vs migrate_misplaced_transhuge_page race condition Andrea Arcangeli
2018-10-15 11:33 ` Mel Gorman
2018-10-15 15:30 ` Kirill A. Shutemov
2018-10-13 0:24 ` [PATCH 2/3] mm: thp: fix mmu_notifier in migrate_misplaced_transhuge_page() Andrea Arcangeli
2018-10-15 11:36 ` Mel Gorman
2018-10-15 15:33 ` Kirill A. Shutemov
2018-10-15 15:38 ` Aaron Tomlin
2018-10-13 0:24 ` [PATCH 3/3] mm: thp: relocate flush_cache_range() " Andrea Arcangeli
2018-10-14 9:58 ` kbuild test robot
2018-10-14 19:58 ` Andrea Arcangeli
2018-10-15 15:35 ` Kirill A. Shutemov
2018-10-15 20:23 ` [PATCH 1/1] " Andrea Arcangeli
2018-10-15 22:11 ` Andrew Morton
2018-10-15 22:52 ` Andrew Morton
2018-10-15 23:03 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181013002430.698-1-aarcange@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=atomlin@redhat.com \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).