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

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] mem_sharing: fix race condition of nominate and unshare
From: Jui-Hao Chiang <juihaochiang@xxxxxxxxx>
Date: Mon, 10 Jan 2011 12:58:31 +0800
Cc: tinnycloud <tinnycloud@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 09 Jan 2011 20:59:34 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lN+FkITuE1VHKWmfp6wNBbuo8x0sPEDA/sUf0k7/MN8=; b=LwSpo5mNQ1mw2ZKWy97pqD00yVflkXCElN3Wj3zgHtQc9XmfaJKiujYL/+KDYrb6iZ Xo2nEr2nAF5L+w5RbnwxwBfLzScOXT9SXnl0yJ1wnORbwUFO2Z8gioa+jiXIhSzM0IQB bw1qW/0o65AIcOoCj2ikY8XO78qhg/W+OcdFM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JBPaoBivN8zriKDMNSQFlvFvCYkkus0+7pvyH7Oa1rtEtqdKMNv0RBaYTh7EW7eLxn iBsoxuxYn4US4MmYFQ+TWiI4CsaTRAhTLyoiON8Br2I5maTUfcjy9CfJlVJw/DSYzvPt xTGA6L9UtRN937ZetjsKjbjsrEX0/+yyOhWBc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikbQbRjmzbJ1g3QzYzLC-5ax9zhdYOKc2okt3bQ@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Sorry, typo

On Mon, Jan 10, 2011 at 12:57 PM, Jui-Hao Chiang <juihaochiang@xxxxxxxxx> wrote:
Hi, Tim:

On Sat, Jan 8, 2011 at 12:09 AM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
At 06:02 +0000 on 07 Jan (1294380120), Jui-Hao Chiang wrote:
> One of the solution is to
> (a) Simply replace shr_lock with p2m_lock.

I think this is the best choice.   If we find that the p2m lock is a
bottleneck we can address it later.


Just to be skeptic.
Why doesn't mfn_to_gfn() take p2m lock when querying the p2m type? Is there any quarantee that the resulting type is correct and

I mean gfn_to_mfn()
 
trustful?
For example:
(1) User1 query the p2m type:
mfn_to_gfn(...&p2mt);
if (p2mt == p2m_ram_rw) /* do something based on the p2m type result? */

(2) User2 modify the p2m type
p2m_lock(p2m);
set_p2m_entry(..... p2m_ram_rw);
p2m_unlock(p2m);

Thanks,
Jui-Hao

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>