Re: [Xen-devel] That xenstored console leak...

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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?

Jim


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