From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH] x86/hap: fix race condition between ENABLE_LOGDIRTY and track_dirty_vram hypercall Date: Thu, 29 Nov 2012 15:40:41 +0000 Message-ID: <20121129154041.GD80627@ocelot.phlegethon.org> References: <50B7087D.20407@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50B7087D.20407@jp.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kouya Shimura Cc: Robert Phillips , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org At 16:02 +0900 on 29 Nov (1354204941), Kouya Shimura wrote: > I'm not sure why paging_lock() is used partially in hap_XXX_vram_tracking > functions. Thus, this patch introduces a new lock. > It would be better to use paging_lock() instead of the new lock > since shadow paging mode (not HAP mode) uses paging_lock to avoid > this race condition. I think you're right - it would be better to use the paging_lock. Cc'ing Robert Phillips, who's got a big patch outstanding that touches the locking in this code. I think the right thing to do is make sure his patch fixes the issue and the backport just the locking parts of it to older trees. Robert, in your patch you do wrap this all in the paging_lock, but then unlock to call various enable and disable routines. Is there a version of this reace condition there, where some other CPU might call LOG_DIRTY_ENABLE while you've temporarily dropped the lock? Cheers, Tim.