From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host
Date: Thu, 23 Aug 2012 15:25:20 +0800 [thread overview]
Message-ID: <5035DAE0.7050901@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120822163746.GU29978@redhat.com>
On 08/23/2012 12:37 AM, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
>> Hmm, in KSM code, i found this code in replace_page:
>>
>> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
>>
>> It is possible to establish a writable pte, no?
>
> Hugh already answered this thanks. Further details on the vm_page_prot
> are in top of mmap.c, and KSM never scans MAP_SHARED vmas.
>
Yes, i see that, thank you, Andrea!
>> Unfortunately, all these bugs are triggered by test cases.
>
> Sure, I've seen the very Oops for the other one, and this one also can
> trigger if unlucky.
>
> This one can trigger with KVM but only if KSM is enabled or with live
> migration or with device hotplug or some other event that triggers a
> fork in qemu.
>
> My curiosity about the other one in the exit/unregister/release paths
> is if it really ever triggered with KVM. Because I can't easily see
> how it could trigger. By the time kvm_destroy_vm or exit_mmap() runs,
> no vcpu can be in guest mode anymore, so it cannot matter whatever the
> status of any leftover spte at that time.
>
vcpu is not in guest mode, but the memory can be still hold in KVM MMU.
Consider this case:
CPU 0 CPU 1
create kvm
create vcpu thread
[ Guest is happily running ]
send kill signal to the process
call do_exit
mmput mm
exit_mmap, then
delete mmu_notify
reclaim the memory of these threads
!!!!!!
Now, the page has been reclaimed but
it is still hold in KVM MMU
mmu_notify->release
!!!!!!
delete spte, and call
mark_page_accessed/mark_page_dirty for
the page which has already been freed on CPU 1
exit_files
release kvm/vcpu file, then
kvm and vcpu are destroyed.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host
Date: Thu, 23 Aug 2012 15:25:20 +0800 [thread overview]
Message-ID: <5035DAE0.7050901@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120822163746.GU29978@redhat.com>
On 08/23/2012 12:37 AM, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
>> Hmm, in KSM code, i found this code in replace_page:
>>
>> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
>>
>> It is possible to establish a writable pte, no?
>
> Hugh already answered this thanks. Further details on the vm_page_prot
> are in top of mmap.c, and KSM never scans MAP_SHARED vmas.
>
Yes, i see that, thank you, Andrea!
>> Unfortunately, all these bugs are triggered by test cases.
>
> Sure, I've seen the very Oops for the other one, and this one also can
> trigger if unlucky.
>
> This one can trigger with KVM but only if KSM is enabled or with live
> migration or with device hotplug or some other event that triggers a
> fork in qemu.
>
> My curiosity about the other one in the exit/unregister/release paths
> is if it really ever triggered with KVM. Because I can't easily see
> how it could trigger. By the time kvm_destroy_vm or exit_mmap() runs,
> no vcpu can be in guest mode anymore, so it cannot matter whatever the
> status of any leftover spte at that time.
>
vcpu is not in guest mode, but the memory can be still hold in KVM MMU.
Consider this case:
CPU 0 CPU 1
create kvm
create vcpu thread
[ Guest is happily running ]
send kill signal to the process
call do_exit
mmput mm
exit_mmap, then
delete mmu_notify
reclaim the memory of these threads
!!!!!!
Now, the page has been reclaimed but
it is still hold in KVM MMU
mmu_notify->release
!!!!!!
delete spte, and call
mark_page_accessed/mark_page_dirty for
the page which has already been freed on CPU 1
exit_files
release kvm/vcpu file, then
kvm and vcpu are destroyed.
next prev parent reply other threads:[~2012-08-23 7:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 9:46 [PATCH] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host Xiao Guangrong
2012-08-21 9:46 ` Xiao Guangrong
2012-08-21 15:06 ` Andrea Arcangeli
2012-08-21 15:06 ` Andrea Arcangeli
2012-08-21 15:06 ` Andrea Arcangeli
2012-08-22 3:51 ` Xiao Guangrong
2012-08-22 3:51 ` Xiao Guangrong
2012-08-22 4:12 ` Hugh Dickins
2012-08-22 4:12 ` Hugh Dickins
2012-08-22 5:37 ` Xiao Guangrong
2012-08-22 5:37 ` Xiao Guangrong
2012-08-22 16:37 ` Andrea Arcangeli
2012-08-22 16:37 ` Andrea Arcangeli
2012-08-23 7:25 ` Xiao Guangrong [this message]
2012-08-23 7:25 ` Xiao Guangrong
2012-08-22 6:03 ` Xiao Guangrong
2012-08-22 6:03 ` Xiao Guangrong
2012-08-22 16:29 ` Andrea Arcangeli
2012-08-22 16:29 ` Andrea Arcangeli
2012-08-22 19:15 ` Andrew Morton
2012-08-22 19:15 ` Andrew Morton
2012-08-22 19:50 ` Andrea Arcangeli
2012-08-22 19:50 ` Andrea Arcangeli
2012-08-22 19:58 ` Andrew Morton
2012-08-22 19:58 ` Andrew Morton
2012-08-22 20:14 ` Andrea Arcangeli
2012-08-22 20:14 ` Andrea Arcangeli
2012-08-23 7:34 ` Xiao Guangrong
2012-08-23 7:34 ` Xiao Guangrong
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=5035DAE0.7050901@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtosatti@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.