From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: That xenstored console leak... Date: Fri, 18 Jan 2008 16:47:21 -0700 Message-ID: <47913A89.50608@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, John Levon List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 18/1/08 23:14, "Jim Fehlig" 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/- >> 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/ path, which is removed when the domain is destroyed. >> >> BTW, with those changesets /vm/ 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//device/vif when attaching/detaching vifs and I notice the /vm/ 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/ 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