Re: That xenstored console leak...

[Jim Fehlig <jfehlig@novell.com>]

Keir Fraser wrote:
> On 18/1/08 23:14, "Jim Fehlig" <jfehlig@novell.com> 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