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] That xenstored console leak...

To: Jim Fehlig <jfehlig@xxxxxxxxxx>
Subject: Re: [Xen-devel] That xenstored console leak...
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 19 Jan 2008 08:11:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 19 Jan 2008 00:12:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47913A89.50608@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchacuoTKOyi9sZmEdyDmgAWy6hiGQ==
Thread-topic: [Xen-devel] That xenstored console leak...
User-agent: Microsoft-Entourage/11.3.6.070618
On 18/1/08 23:47, "Jim Fehlig" <jfehlig@xxxxxxxxxx> wrote:

>>  I guess
>> that's the way to go, if so, and I'll commit to 3.3 and 3.2 trees.
>>   
> 
> Hmm, don't know about replacing one lead with another - although to be
> fair it is much smaller :-).  What about my other suggestion of source
> domain of these operations nuking its /vm/<uuid> path on destruction?  I
> get the feeling there is a race in the localhost migration path that
> prevented such an approach, hence c/s 15957.  I could look into this
> though if you like, but will be out of town for the next few days and
> won't be able to investigate until Tuesday.

It would be nice to reference count, or otherwise track the vm<->domain
mapping, of /vm, so that we could somehow naturally avoid destroying the /vm
path on localhost migration yet we could destroy it on most saves and
relocates. I don't know how hard this would be.

Could we just make all saves and relocates destroy the /vm/<uuid>-<number>
path? I can imagine I missed adding some deletions of that path when I
introduced the <number> extra level of discrimination, but would it be hard
to find the one or two places it might be needed and add it? Compared with
the other options we have?

I'm afraid I'm really not sure -- but I suspect at this point you know xend
a bit better than I do.

 -- Keir



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