From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v3 5/9] KVM: MMU: introduce SPTE_WRITE_PROTECT bit Date: Sat, 21 Apr 2012 12:29:44 +0800 Message-ID: <4F9237B8.9090503@gmail.com> References: <4F911B74.4040305@linux.vnet.ibm.com> <4F911C05.2070701@linux.vnet.ibm.com> <20120420215211.GC13817@amt.cnet> <20120421004030.GA16191@amt.cnet> <20120421005555.GA16526@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Xiao Guangrong , Avi Kivity , LKML , KVM To: Marcelo Tosatti Return-path: In-Reply-To: <20120421005555.GA16526@amt.cnet> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 04/21/2012 08:55 AM, Marcelo Tosatti wrote: >> So this is an example of implicit assumptions which break if you update >> spte without mmu_lock. Certainly there are more cases. :( > > OK, i now see you mentioned a similar case in the document, for > rmap_write_protect. > > More importantly than the particular flush TLB case, the point is > every piece of code that reads and writes sptes must now be aware that > mmu_lock alone does not guarantee stability. Everything must be audited. > Yes, that is true, but it is not hard to audit the code since we only change the spte from read-only to writable, also all information that fast page fault depends on is from spte.