Re: [Xen-devel] [PATCH 0/4] Fix to libxl migration v2 issue blocking OSSTest

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-07-21 at 15:51 +0100, Ian Campbell wrote:
> On Tue, 2015-07-21 at 13:49 +0100, Wei Liu wrote:
> > On Mon, Jul 20, 2015 at 11:11:28AM +0100, Andrew Cooper wrote:
> > > On 20/07/15 10:56, Wei Liu wrote:
> > > > On Fri, Jul 17, 2015 at 05:51:14PM +0100, Andrew Cooper wrote:
> > > > > And three improvements to debugging.
> > > > > 
> > > > > Note that there is still a bug in libxl__toolstack_save() 
> > > > > which
> > > > > valgrind identified, but I do not wish to block this bugfix 
> > > > > on 
> > > > > that
> > > > > 
> > > > > Andrew Cooper (4):
> > > > >   tools/libxc: Identify the path of the kernel image which 
> > > > > cannot be
> > > > >     found
> > > > >   tools/libxl: Log the subject fd in datacopier messages
> > > > >   tools/libxl: Identify copywhat in stream v2 datacopiers
> > > > I think all three patches should wait until next development 
> > > > window
> > > > opens unless we have nothing else in our queue (which doesn't 
> > > > seem to be
> > > > the case at the moment).
> > > 
> > > You mean delay until 4.7? I disagree.  Without these fixes, 
> > > debugging
> > > issues is substantially harder than they need to be.
> > > 
> > > They literally are only adding extra information into existing 
> > > error
> > > messages.
> > > 
> > 
> > Well I am expecting two to three big series getting applied soon, 
> > any
> > changes that gets applied now has the chance of forcing those 
> > series 
> > to
> > be rebased.
> 
> Wei and I discussed this IRL, the concern was the outstanding colopre
> patches.
> 
> However I did a test apply on top of  
> https://github.com/macrosheep/xen.git#colo/colo-v9 (the latest 
> colopre)
> and there were no rejects due to the remus refactoring.
> 
> There were rejects because I already applied 4/4 on Friday, i.e. they
> were the inverse of what I fixed up then.
> 
> So given the lack of interaction with colopre Wei gave me permission 
> to
> go ahead, so I have applied patches 1..3.
> 
> 4 was applied already, of course.

In doing this I managed to revert part of #4, thanks to Andy for
noticing so promptly.

I've pushed the following:

From 1287ac109c44ca9b99eb642316d7af83b4081b52 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Tue, 21 Jul 2015 16:00:19 +0100
Subject: [PATCH] tools: libxl: Refix "Initialise the fd of the unused half of
 a datacopier"

Applying the series out of order led to d72befc35f31 "tools/libxl:
Identify copywhat in stream v2 datacopiers" unintentionally reverting
part of 21d9b079e538 "tools/libxl: Initialise the fd of the unused
half of a datacopier".

Put this back.

Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
---
 tools/libxl/libxl_stream_read.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index 3e1cd2a..32a3551 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -611,6 +611,7 @@ static void write_emulator_blob(libxl__egc *egc,
     dc->writewhat  = "qemu save file";
     dc->copywhat   = "restore v2 stream";
     dc->writefd    = writefd;
+    dc->readfd     = -1;
     dc->maxsz      = -1;
     dc->callback   = write_emulator_done;
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel