From: Sean Christopherson <sean.j.christopherson@intel.com>
To: "Longpeng (Mike)" <longpeng2@huawei.com>
Cc: mike.kravetz@oracle.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
arei.gonglei@huawei.com, weidong.huang@huawei.com,
weifuqiang@huawei.com, kvm@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: avoid get wrong ptep caused by race
Date: Wed, 19 Feb 2020 08:22:31 -0800 [thread overview]
Message-ID: <20200219162231.GE15888@linux.intel.com> (raw)
In-Reply-To: <6ccbde03-953c-c006-a07e-8146b84389d9@huawei.com>
On Wed, Feb 19, 2020 at 08:21:26PM +0800, Longpeng (Mike) wrote:
> 在 2020/2/19 9:58, Sean Christopherson 写道:
> > FWIW, I'd be in favor of going the READ/WRITE_ONCE() route for x86, e.g.
> > convert everything as a follow-up patch (or patches). I'm fairly confident
> > that KVM's usage of lookup_address_in_mm() is safe, but I wouldn't exactly
> > bet my life on it. I'd much rather the failing scenario be that KVM uses
> > a sub-optimal page size as opposed to exploding on a bad pointer.
> >
> Um...our testcase starts 50 VMs with 2U4G(use 1G hugepage) and then do
> live-upgrade(private feature that just modify the qemu and libvirt) and
> live-migrate in turns for each one. However our live upgraded new QEMU won't do
> touch_all_pages.
> Suppose we start a VM without touch_all_pages in QEMU, the VM's guest memory is
> not mapped in the CR3 pagetable at the moment. When the 2 vcpus running, they
> could access some pages belong to the same 1G-hugepage, both of them will vmexit
> due to ept_violation and then call gup-->follow_hugetlb_page-->hugetlb_fault, so
> the race may encounter, right?
Yep. The code I'm referring to is similar but different code that just
happened to go into KVM for kernel 5.6. It has no effect on the gup() flow
that leads to this bug. I mentioned it above as an example of code outside
of hugetlb_fault() that would also benefit from moving to READ/WRITE_ONCE().
next prev parent reply other threads:[~2020-02-19 16:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 12:10 [PATCH] mm/hugetlb: avoid get wrong ptep caused by race Longpeng(Mike)
2020-02-18 20:37 ` Sean Christopherson
2020-02-19 0:51 ` Mike Kravetz
2020-02-19 1:39 ` Longpeng (Mike)
2020-02-19 1:58 ` Sean Christopherson
2020-02-19 12:21 ` Longpeng (Mike)
2020-02-19 16:22 ` Sean Christopherson [this message]
2020-02-20 2:32 ` Longpeng (Mike)
2020-02-19 19:33 ` Mike Kravetz
2020-02-20 2:30 ` Longpeng (Mike)
2020-02-21 0:22 ` Mike Kravetz
2020-02-22 2:15 ` Longpeng (Mike)
2020-02-18 20:52 ` Matthew Wilcox
2020-02-19 2:09 ` Longpeng (Mike)
2020-02-19 3:49 ` Mike Kravetz
2020-02-19 12:52 ` Longpeng (Mike)
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=20200219162231.GE15888@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arei.gonglei@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longpeng2@huawei.com \
--cc=mike.kravetz@oracle.com \
--cc=weidong.huang@huawei.com \
--cc=weifuqiang@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;
as well as URLs for NNTP newsgroup(s).