From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 0/2 V3] fix rename: xenstore not fully updated Date: Wed, 19 Nov 2014 16:25:06 -0500 Message-ID: <20141119212505.GJ20440@laptop.dumpdata.com> References: <1416378851-32236-1-git-send-email-cyliu@suse.com> <21612.32360.328456.516321@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <21612.32360.328456.516321@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Chunyan Liu , wei.liu2@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote: > 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//name, > > still some places in xenstore are not updated, including: > > /vm//name and /local/domain/0/backend///.../domain. > > This patch series updates /vm//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. When was this introduced? Did it exist with Xend? > > 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. I checked QEMU and didn't find anything in there. > > > > 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.