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/
Home Products Support Community News


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:14:16 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Jan 2008 15:15:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: C3B21B02.122B6%Keir.Fraser@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060911)
Keir Fraser wrote:

>> Reverting changesets 15967 and 15957 in addition to the attached patch
>> fixes the leak and allows multiple localhost migrations.  I'm not sure
>> what we get by nuking /vm/<uuid>/device/vif/<dev_num> anyway - other
>> than the problems we're seeing :-). vif appears to be the only device
>> stored in the /vm/<uuid>/device path anyway.
>> I will continue testing with this setup ...
> Isn't having two domains (even from the same vm) pointing at the same /vm/
> path a recipe for further bugs? Most of the lowlevel xend code doesn't seem
> to understand the concept that domains can map to the same vm, and could
> hence tread on each others toes via the /vm/ path.
> If we revert the two patches, what happens when you create/destroy lots of
> domains all with different uuids? I expect the leak will still exist in that
> case.

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?


Xen-devel mailing list