Re: [PATCH 0/2 V3] fix rename: xenstore not fully updated

From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: konrad.wilk@oracle.com
Cc: Chunyan Liu <cyliu@suse.com>,
	wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 0/2 V3] fix rename: xenstore not fully updated
Date: Wed, 19 Nov 2014 11:26:32 +0000	[thread overview]
Message-ID: <21612.32360.328456.516321@mariner.uk.xensource.com> (raw)
In-Reply-To: <1416378851-32236-1-git-send-email-cyliu@suse.com>

Hi Konrad, I have another release ack request:

Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain/<domid>/name,
> still some places in xenstore are not updated, including:
> /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> This patch series updates /vm/<uuid>/name in xenstore,

This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
bugfix which I think should go into Xen 4.5.

The risk WITHOUT this patch is that there are out-of-tree tools which
look here for the domain name and will get confused after it is
renamed.

The risk WITH this patch is that the implementation could be wrong
somehow, in which case the code would need to be updated again.  But
it's a very small patch and has been fully reviewed.

> and removes the unusual 'domain' field under backend directory.

This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
backend dir".  The change to libxl is that it no longer writes
  /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"

It seems hardly conceivable that anyone could be using this field.
Existing users will not work after the domain is renamed, anyway.

The risk on both sides of the decision lies entirely with out-of-tree
software which looks here for the domain name for some reason.  We
don't think any such tools exist.

Note that the domain name cannot be used directly by a non-dom0
programs because the mapping between domids and domain names is in a
part of xenstore which is not accessible to guests.  (It is possible
that a guest would read this value merely to display it.)

If such out-of-tree software exists:

The risk WITHOUT this patch is that it might report, or (worse)
operate on, the wrong domain entirely.

The risk WITH this patch is that it (or some subset of its
functionality) would stop working right away.

An alternative would be to update all of these entries on rename.
That's a large and somewhat fiddly patch which we don't think is
appropriate given that the presence of this key is a mistake.

Thanks,
ian.