All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhanghailiang <zhang.zhanghailiang@huawei.com>
To: Lukas Straub <lukasstraub2@web.de>
Cc: Zhang Chen <chen.zhang@intel.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: RE: [PATCH 6/6] migration/colo.c: Move colo_notify_compares_event to the right place
Date: Fri, 15 May 2020 01:45:52 +0000	[thread overview]
Message-ID: <4980bdc049ec41c5bb5995a0c8a9ffed@huawei.com> (raw)
In-Reply-To: <20200514163105.14d7b97d@luklap>

> -----Original Message-----
> From: Lukas Straub [mailto:lukasstraub2@web.de]
> Sent: Thursday, May 14, 2020 10:31 PM
> To: Zhanghailiang <zhang.zhanghailiang@huawei.com>
> Cc: qemu-devel <qemu-devel@nongnu.org>; Zhang Chen
> <chen.zhang@intel.com>; Juan Quintela <quintela@redhat.com>; Dr. David
> Alan Gilbert <dgilbert@redhat.com>
> Subject: Re: [PATCH 6/6] migration/colo.c: Move
> colo_notify_compares_event to the right place
> 
> On Thu, 14 May 2020 13:27:30 +0000
> Zhanghailiang <zhang.zhanghailiang@huawei.com> wrote:
> 
> > Cc: Zhang Chen <chen.zhang@intel.com>
> >
> > >
> > > If the secondary has to failover during checkpointing, it still is
> > > in the old state (i.e. different state than primary). Thus we can't
> > > expose the primary state until after the checkpoint is sent.
> > >
> >
> > Hmm, do you mean we should not flush the net packages to client
> > connection until checkpointing Process almost success because it may fail
> during checkpointing ?
> 
> No.
> If the primary fails/crashes during checkpointing, the secondary is still in
> different state than the primary because it didn't receive the full checkpoint.
> We can release the miscompared packets only after both primary and
> secondary are in the same state.
> 
> Example:
> 1. Client opens a TCP connection, sends SYN.
> 2. Primary accepts the connection with SYN-ACK, but due to
> nondeterministic execution the secondary is delayed.
> 3. Checkpoint happens, primary releases the SYN-ACK packet but then
> crashes while sending the checkpoint.
> 4. The Secondary fails over. At this point it is still in the old state where it
> hasn't sent the SYN-ACK packet.
> 5. The client responds with ACK to the SYN-ACK packet.
> 6. Because it doesn't know the connection, the secondary responds with RST,
> connection reset.
> 

Good example. For this patch, it is OK, I will add reviewed-by in your origin patch.


> Regards,
> Lukas Straub
> 
> > > This fixes sporadic connection reset of client connections during failover.
> > >
> > > Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> > > ---
> > >  migration/colo.c | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/migration/colo.c b/migration/colo.c index
> > > a69782efc5..a3fc21e86e 100644
> > > --- a/migration/colo.c
> > > +++ b/migration/colo.c
> > > @@ -430,12 +430,6 @@ static int
> > > colo_do_checkpoint_transaction(MigrationState *s,
> > >          goto out;
> > >      }
> > >
> > > -    qemu_event_reset(&s->colo_checkpoint_event);
> > > -    colo_notify_compares_event(NULL, COLO_EVENT_CHECKPOINT,
> > > &local_err);
> > > -    if (local_err) {
> > > -        goto out;
> > > -    }
> > > -
> > >      /* Disable block migration */
> > >      migrate_set_block_enabled(false, &local_err);
> > >      qemu_mutex_lock_iothread();
> > > @@ -494,6 +488,12 @@ static int
> > > colo_do_checkpoint_transaction(MigrationState *s,
> > >          goto out;
> > >      }
> > >
> > > +    qemu_event_reset(&s->colo_checkpoint_event);
> > > +    colo_notify_compares_event(NULL, COLO_EVENT_CHECKPOINT,
> > > &local_err);
> > > +    if (local_err) {
> > > +        goto out;
> > > +    }
> > > +
> > >      colo_receive_check_message(s->rp_state.from_dst_file,
> > >                         COLO_MESSAGE_VMSTATE_LOADED,
> &local_err);
> > >      if (local_err) {
> > > --
> > > 2.20.1



  reply	other threads:[~2020-05-15  1:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 11:10 [PATCH 0/6] colo: migration related bugfixes Lukas Straub
2020-05-11 11:10 ` [PATCH 1/6] migration/colo.c: Use event instead of semaphore Lukas Straub
2020-05-13 11:31   ` 答复: " Zhanghailiang
2020-05-11 11:10 ` [PATCH 2/6] migration/colo.c: Use cpu_synchronize_all_states() Lukas Straub
2020-05-13  9:47   ` Dr. David Alan Gilbert
2020-05-13 19:15     ` Lukas Straub
2020-05-11 11:10 ` [PATCH 3/6] migration/colo.c: Flush ram cache only after receiving device state Lukas Straub
2020-05-14 12:45   ` 答复: " Zhanghailiang
2020-05-11 11:10 ` [PATCH 4/6] migration/colo.c: Relaunch failover even if there was an error Lukas Straub
2020-05-15  6:24   ` Zhanghailiang
2020-05-11 11:10 ` [PATCH 5/6] migration/qemu-file.c: Don't ratelimit a shutdown fd Lukas Straub
2020-05-14 13:05   ` 答复: " Zhanghailiang
2020-05-18 11:55     ` Dr. David Alan Gilbert
2020-05-19 13:08       ` Lukas Straub
2020-05-19 14:50         ` Dr. David Alan Gilbert
2020-05-20 20:44           ` Lukas Straub
2020-05-11 11:11 ` [PATCH 6/6] migration/colo.c: Move colo_notify_compares_event to the right place Lukas Straub
2020-05-14 13:27   ` 答复: " Zhanghailiang
2020-05-14 14:31     ` Lukas Straub
2020-05-15  1:45       ` Zhanghailiang [this message]
2020-05-15  1:53   ` Zhanghailiang
2020-06-01 16:50 ` [PATCH 0/6] colo: migration related bugfixes Dr. David Alan Gilbert

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=4980bdc049ec41c5bb5995a0c8a9ffed@huawei.com \
    --to=zhang.zhanghailiang@huawei.com \
    --cc=chen.zhang@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=lukasstraub2@web.de \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.