xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 0/4] Fix to libxl migration v2 issue blocking OSSTest
Date: Tue, 21 Jul 2015 16:05:19 +0100	[thread overview]
Message-ID: <1437491119.8383.53.camel@citrix.com> (raw)
In-Reply-To: <1437490290.8383.50.camel@citrix.com>

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@citrix.com>
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@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 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

      reply	other threads:[~2015-07-21 15:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 16:51 [PATCH 0/4] Fix to libxl migration v2 issue blocking OSSTest Andrew Cooper
2015-07-17 16:51 ` [PATCH 1/4] tools/libxc: Identify the path of the kernel image which cannot be found Andrew Cooper
2015-07-17 16:53   ` Ian Campbell
2015-07-17 16:55   ` Wei Liu
2015-07-17 16:51 ` [PATCH 2/4] tools/libxl: Log the subject fd in datacopier messages Andrew Cooper
2015-07-20  9:54   ` Wei Liu
2015-07-17 16:51 ` [PATCH 3/4] tools/libxl: Identify copywhat in stream v2 datacopiers Andrew Cooper
2015-07-20  9:55   ` Wei Liu
2015-07-17 16:51 ` [PATCH 4/4] tools/libxl: Initialise the fd of the unused half of a datacopier Andrew Cooper
2015-07-17 16:55   ` Ian Campbell
2015-07-17 16:55   ` Wei Liu
2015-07-17 16:56     ` Andrew Cooper
2015-07-17 16:59     ` [PATCH v2 " Andrew Cooper
2015-07-17 17:01       ` Wei Liu
2015-07-17 17:11         ` Ian Campbell
2015-07-17 17:11           ` Andrew Cooper
2015-07-20  9:56 ` [PATCH 0/4] Fix to libxl migration v2 issue blocking OSSTest Wei Liu
2015-07-20 10:11   ` Andrew Cooper
2015-07-21 12:49     ` Wei Liu
2015-07-21 14:51       ` Ian Campbell
2015-07-21 15:05         ` Ian Campbell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1437491119.8383.53.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).