linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: zhong jiang <zhongjiang@huawei.com>
Cc: vbabka@suse.cz, qiuxishi@huawei.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, Mike Kravetz <mike.kravetz@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH v2] mm/hugetlb: fix race when migrate pages
Date: Wed, 20 Jul 2016 15:24:31 +0200	[thread overview]
Message-ID: <20160720132431.GM11249@dhcp22.suse.cz> (raw)
In-Reply-To: <20160720130055.GL11249@dhcp22.suse.cz>

[Sorry for spammin, I though my headache would force me to not stare
 into the code more but I couldn't resist ]
On Wed 20-07-16 15:00:55, Michal Hocko wrote:
> On Wed 20-07-16 14:45:01, Michal Hocko wrote:
> [...]
> > I was talking to Mel (CCed) and he has raised a good question. So if you
> > encounter a page under migration and fail to share the pmd with it how
> > can you have a proper content of the target page in the end?
> 
> Hmm, I was staring into the code some more and it seems this would be OK
> because we should hit hugetlb_no_page with the newel instantiated pmd
> and associate it with a page from the radix tree. So unless I am missing
> something the corruption shouldn't be possible.
> 
> I believe the post pmd_populate race is still there, though, so I
> believe the approach should be rethought.

So I think the swap entry is OK in fact. huge_pte_alloc would return a
shared pmd which would just happen to be swap entry. hugetlb_fault would
then recognize that by:
	/*
	 * entry could be a migration/hwpoison entry at this point, so this
	 * check prevents the kernel from going below assuming that we have
	 * a active hugepage in pagecache. This goto expects the 2nd page fault,
	 * and is_hugetlb_entry_(migration|hwpoisoned) check will properly
	 * handle it.
	 */
	if (!pte_present(entry))
		goto out_mutex;

We would get back from the page fault and if the page was still under
migration on the retry we would end up waiting for the migration entry
on the next fault.

	ptep = huge_pte_offset(mm, address);
	if (ptep) {
		entry = huge_ptep_get(ptep);
		if (unlikely(is_hugetlb_entry_migration(entry))) {
			migration_entry_wait_huge(vma, mm, ptep);
			return 0;

Or am I missing something? If not we should just reconsider the BUG_ON
but I still have to think wether it is useful/needed at all.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-07-20 13:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 13:45 zhongjiang
2016-07-20  7:38 ` Michal Hocko
2016-07-20 10:03   ` zhong jiang
2016-07-20 12:16     ` Michal Hocko
2016-07-20 12:45       ` Michal Hocko
2016-07-20 13:00         ` Michal Hocko
2016-07-20 13:24           ` Michal Hocko [this message]
2016-07-21  9:25             ` zhong jiang
  -- strict thread matches above, loose matches on Subject: below --
2016-07-19 13:04 zhongjiang

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=20160720132431.GM11249@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=qiuxishi@huawei.com \
    --cc=vbabka@suse.cz \
    --cc=zhongjiang@huawei.com \
    /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