WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] mem_sharing: fix race condition of nominate

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] mem_sharing: fix race condition of nominate and unshare
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 12 Jan 2011 11:50:56 +0000
Cc: tinnycloud <tinnycloud@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jui-Hao Chiang <juihaochiang@xxxxxxxxx>
Delivery-date: Wed, 12 Jan 2011 03:51:36 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DjXufC53JGShKc2j6Gzjbg5/j7E5OAqJ2wtrIkZb6OY=; b=uAWH0lFcBu82eAukp7yJTHOQ/II5APfKh8Kh36XCtaYThr7X5yseqGrEvaYIJAC5lQ ikL8jRcp5sup/CCWnHA5iQez7zi3rMRkINrlamFj2OablDKlEE4YMSti4MGv2nTx0Efi 9W30VXogJOe854BrrX2tk1DlkYfYSrJctN754=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=TK5mH+q11O6/cq+RustIJHz+u72JBc6bbq9iVVEGRX3AAckYigs03cB4i3CKW3HOfs 9pD4quCGVEK56evBvMrqwqh/8t5c0LlbQ4sflWfgbDyx8lB1dbaercQEdO86mnFxVp+L oEDCca+zNKi8eoNkFYWpHIMphuxQMRcKUYsdE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110110103041.GE5651@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTinMp1v1zex2BfcUuszotPuxJFWZQNUp40gu_gxL@xxxxxxxxxxxxxx> <20110106165450.GO21948@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTinmpiusLqegGZA+bZWpDXPM+7Wq2nt8MZa0Ocet@xxxxxxxxxxxxxx> <AANLkTinf-A_4NEPQeCw0pftM5Bks8BYPRhMx3-stTHxa@xxxxxxxxxxxxxx> <20110107160949.GD5651@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTikbQbRjmzbJ1g3QzYzLC-5ax9zhdYOKc2okt3bQ@xxxxxxxxxxxxxx> <20110110103041.GE5651@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, Jan 10, 2011 at 10:30 AM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
>> Just to be skeptic.
>> Why doesn't mfn_to_gfn() take p2m lock when querying the p2m type?
>
> Because gfn->mfn lookups happen very frequently and requiring the lock
> would be a performance bottleneck on multi-vcpu guests.

I think there's also a deadlock issue.  At some point a few months ago
I made ept_get_entry() grab the p2m lock, and it deadlocked with the
paging lock.  IIRC, the problem was that
* Sometimes the paging lock is grabbed after the p2m lock is taken
* Sometimes gfn_to_mfn() is called when the paging lock is held

So adding the p2m lock to gfn_to_mfn() gave you a circular lock
dependency, classic condition for deadlock.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>