From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] load_pdptrs cleanups Date: Thu, 26 Jul 2007 08:14:10 +0300 Message-ID: <46A82DA2.2050708@qumranet.com> References: <1185334191.1803.464.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Rusty Russell Return-path: In-Reply-To: <1185334191.1803.464.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Rusty Russell wrote: > load_pdptrs can be handed an invalid cr3, and it should not oops. > This can happen because we injected #gp in set_cr3() after we set > vcpu->cr3 to the invalid value, or from kvm_vcpu_ioctl_set_sregs(), or > possibly (?) memory configuration changes after the guest did > set_cr3(). > > We should also copy the pdpte array once, before checking and > assigning, otherwise an SMP guest can potentially alter the values > between the check and the set. > > Finally one nitpick: ret = 1 should be done as late as possible: this > allows GCC to check for unset "ret" should the function change in > future. > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/