From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH for 3.3] KVM: Fix write protection race during dirty logging Date: Mon, 06 Feb 2012 12:46:14 +0900 Message-ID: <4F2F4D06.8020303@oss.ntt.co.jp> References: <20120205204241.54f16069c7f10ac7524c55ec@gmail.com> <4F2F4B99.6050902@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org To: Xiao Guangrong Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:56568 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753175Ab2BFDo2 (ORCPT ); Sun, 5 Feb 2012 22:44:28 -0500 In-Reply-To: <4F2F4B99.6050902@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: (2012/02/06 12:40), Xiao Guangrong wrote: > On 02/05/2012 07:42 PM, Takuya Yoshikawa wrote: > >> From: Takuya Yoshikawa >> >> This patch fixes a race introduced by: >> >> commit 95d4c16ce78cb6b7549a09159c409d52ddd18dae >> KVM: Optimize dirty logging by rmap_write_protect() >> >> During protecting pages for dirty logging, other threads may also try >> to protect a page in mmu_sync_children() or kvm_mmu_get_page(). >> >> In such a case, because get_dirty_log releases mmu_lock before flushing >> TLB's, the following race condition can happen: >> >> A (get_dirty_log) B (another thread) >> >> lock(mmu_lock) >> clear pte.w >> unlock(mmu_lock) >> lock(mmu_lock) >> pte.w is already cleared >> unlock(mmu_lock) >> skip TLB flush >> return >> ... >> TLB flush >> >> Though thread B assumes the page has already been protected when it >> returns, the remaining TLB entry will break that assumption. >> >> This patch fixes this problem by making get_dirty_log hold the mmu_lock >> until it flushes the TLB's. >> > > > I do not think this is a problem since the dirty page is logged when > the writeable spte is being set, and in the end of get_dirty_log, all > TLBs are always flushed. > The victim is not GET_DIRTY_LOG but thread B; it needs to assure the page is protected before returning. Thanks, Takuya