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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] That xenstored console leak...
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Fri, 18 Jan 2008 16:47:21 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Jan 2008 15:48:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3B6E43A.12829%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <C3B6E43A.12829%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.8 (X11/20060911)
Keir Fraser wrote:
> On 18/1/08 23:14, "Jim Fehlig" <jfehlig@xxxxxxxxxx> wrote:
>
>   
>> Sorry for the delay.  I'm not sure why you think that the leak would
>> still exist with those changesets reverted.  15957 (and subsequently
>> 15967) introduced the leak by creating a whole new /vm/<uuid>-<num>
>> path, leaving the previous path orphaned.  But I certainly don't claim
>> to be an expert on this code so perhaps I'm not understanding your concern.
>>
>> Nevertheless, I created/destroyed lots of domains on 3.2 with those
>> changesets reverted and do not see the leak.  However I wouldn't expect
>> so since each domain has a different uuid and hence a different
>> /vm/<uuid> path, which is removed when the domain is destroyed.
>>
>> BTW, with those changesets /vm/<uuid> path is leaked on save/restore,
>> reboot, and localhost migration.  Perhaps the source domain in these
>> operations should be removing its /vm path on destruction?
>>     
>
> Okay, so with the two patches reverted plus your patch, there seem to be no
> leaks, and MAC addresses are not lost across localhost relocations?

Correct.  But we do leak, as discussed earlier, /vm/<uuid>/device/vif
when attaching/detaching vifs and I notice the /vm/<uuid> path remains
after a save operation.

>  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.

> I suppose your patch should also be applicable to 3.1?
>   

It appears so by glancing at the code, but I don't have a 3.1 system
handy atm to verify.

Jim


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