Sean Dague
2005-Oct-06 13:47 UTC
[Xen-devel] Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain
So what happens if: * Dom1 is told to die * It doesn''t because it can''t free a physical resource (i.e. disk) * It gets renamed to Zombie-Dom1 * User tries to recreate Dom1 * New Dom1 grabs physical resource that was keeping Dom1 from dying Doesn''t that provide for the possibility of 2 writers to a device that only can support 1, and all heck breaking loose? (Note, I hope I''m wrong here) It seems that this just moves the race to somewhere more dangerous. -Sean On Thu, Oct 06, 2005 at 10:16:12AM +0000, Xen patchbot -unstable wrote:> Diffstat output: > > XendDomainInfo.py | 33 ++++++++++++++++++++++----------- > 1 files changed, 22 insertions(+), 11 deletions(-) > > # HG changeset patch > # User emellor@ewan > # Node ID 0bc466c255605d0efeb4803626b72415839b9e6c > # Parent 1cfe0875658d5f83d38a5d96abe7a66e0d5db508 > Rename all dying domains to be prefixed with Zombie. This allows a new domain > to be created with the same name, fixing the race condition inside XendDomain > that caused bug #278. > > Move the state_set(TERMINATED) call onto the end of cleanupDomain rather than > destroyDomain, so that this flag is set when XendDomain cleans up a domain > that was killed without going through Xend. > > Remove is_terminated, as this check is no longer necessary, since we are using > Zombie prefixes instead. > > Signed-off-by: Ewan Mellor <ewan@xensource.com> > > diff -r 1cfe0875658d -r 0bc466c25560 tools/python/xen/xend/XendDomainInfo.py > --- a/tools/python/xen/xend/XendDomainInfo.py Thu Oct 6 10:04:49 2005 > +++ b/tools/python/xen/xend/XendDomainInfo.py Thu Oct 6 10:09:14 2005 > @@ -97,6 +97,7 @@ > DOMROOT = ''/local/domain/'' > VMROOT = ''/vm/'' > > +ZOMBIE_PREFIX = ''Zombie-'' > > xc = xen.lowlevel.xc.new() > xroot = XendRoot.instance() > @@ -997,8 +998,6 @@ > dominfo = domain_by_name(name) > if not dominfo: > return > - if dominfo.is_terminated(): > - return > if self.domid is None: > raise VmError("VM name ''%s'' already in use by domain %d" % > (name, dominfo.domid)) > @@ -1100,6 +1099,14 @@ > except: > log.exception("Removing domain path failed.") > > + try: > + if not self.info[''name''].startswith(ZOMBIE_PREFIX): > + self.info[''name''] = self.generateZombieName() > + except: > + log.exception("Renaming Zombie failed.") > + > + self.state_set(STATE_VM_TERMINATED) > + > > def cleanupVm(self): > """Cleanup VM resources. Idempotent. Nothrow guarantee.""" > @@ -1123,23 +1130,15 @@ > log.debug("XendDomainInfo.destroyDomain(%s)", str(self.domid)) > > self.cleanupDomain() > - > + > try: > if self.domid is not None: > xc.domain_destroy(dom=self.domid) > except: > log.exception("XendDomainInfo.destroy: xc.domain_destroy failed.") > > - self.state_set(STATE_VM_TERMINATED) > - > > ## private: > - > - def is_terminated(self): > - """Check if a domain has been terminated. > - """ > - return self.state == STATE_VM_TERMINATED > - > > def release_devices(self): > """Release all domain''s devices. Nothrow guarantee.""" > @@ -1353,6 +1352,18 @@ > n += 1 > > > + def generateZombieName(self): > + n = 0 > + name = ZOMBIE_PREFIX + self.info[''name''] > + while True: > + try: > + self.check_name(name) > + return name > + except VmError: > + n += 1 > + name = "%s%d-%s" % (ZOMBIE_PREFIX, n, self.info[''name'']) > + > + > def configure_bootloader(self): > if not self.info[''bootloader'']: > return > > _______________________________________________ > Xen-changelog mailing list > Xen-changelog@lists.xensource.com > http://lists.xensource.com/xen-changelog >-- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor
2005-Oct-06 13:57 UTC
Re: [Xen-devel] Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain
On Thu, Oct 06, 2005 at 09:47:23AM -0400, Sean Dague wrote:> So what happens if: > > * Dom1 is told to die > * It doesn''t because it can''t free a physical resource (i.e. disk) > * It gets renamed to Zombie-Dom1 > * User tries to recreate Dom1 > * New Dom1 grabs physical resource that was keeping Dom1 from dying > > Doesn''t that provide for the possibility of 2 writers to a device that only > can support 1, and all heck breaking loose? (Note, I hope I''m wrong here)If a domain has been destroyed, even if it''s a zombie in the dying state, it will never execute another instruction. Xen may be unable to clean up after it, but you are guaranteed that it won''t write to the filesystem any longer. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2005-Oct-06 15:14 UTC
Re: [Xen-devel] Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain
Ewan Mellor wrote:>On Thu, Oct 06, 2005 at 09:47:23AM -0400, Sean Dague wrote: > > >If a domain has been destroyed, even if it''s a zombie in the dying state, it >will never execute another instruction. Xen may be unable to clean up after >it, but you are guaranteed that it won''t write to the filesystem any longer. > >It doesn''t need to. There''s no guarentee that the backend has flushed all of the data in the write queue until after the domain has been destroyed. You could potentially have a domain read from a block device and then the dying domain flush some changes to the disk and end up with a corrupted disk. Regards, Anthony Liguori>Ewan. > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
harry
2005-Oct-06 17:37 UTC
Re: [Xen-devel] Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain
IIUC, in the case you describe below, the data is good data from the old domain instance (the shared pages pinned by the BE still contain the data the FE intended right?), the only problem is if it gets written after the new domain instance performs a read or write to an overlapping extent. I think this requires some kind of equivalent of "clear task set" to ensure that all IO from the old domain instance is killed before the new domain instance starts doing any. There''s a different case where you unload a driver and want to free up the shared page. It''s necessary to make sure that the BE stops looking at the shared page before the FE frees it for a different purpose. This second case is also subtle because the way the rings work means that even if there is no IO outstanding in the BE it is still possible that there is an interrupt pending in the BE to look at the ring. If the ring is freed up whilst there is an interrupt pending then the interrupt may see ring contents which cause a spurious write. This second case requires an explicit handshake with the BE to unload a driver module. Harry. On Thu, 2005-10-06 at 10:14 -0500, Anthony Liguori wrote:> Ewan Mellor wrote: > > >On Thu, Oct 06, 2005 at 09:47:23AM -0400, Sean Dague wrote: > > > > > >If a domain has been destroyed, even if it''s a zombie in the dying state, it > >will never execute another instruction. Xen may be unable to clean up after > >it, but you are guaranteed that it won''t write to the filesystem any longer. > > > > > It doesn''t need to. There''s no guarentee that the backend has flushed > all of the data in the write queue until after the domain has been > destroyed. > > You could potentially have a domain read from a block device and then > the dying domain flush some changes to the disk and end up with a > corrupted disk. > > Regards, > > Anthony Liguori > > >Ewan. > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xensource.com > >http://lists.xensource.com/xen-devel > > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel