Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain

Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain

[Sean Dague]

[-- Attachment #1.1: Type: text/plain, Size: 4615 bytes --]

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.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain

[Ewan Mellor]

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.

Re: Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain

[Anthony Liguori]

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
>
>  
>

Re: Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain

[harry]

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
>