qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 1/4] qemu-file: Don't do IO after shutdown
Date: Wed, 18 Dec 2019 15:24:06 +0000	[thread overview]
Message-ID: <20191218152406.GH3707@work-vm> (raw)
In-Reply-To: <87d0cl66sa.fsf@trasno.org>

* Juan Quintela (quintela@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > * Juan Quintela (quintela@redhat.com) wrote:
> >> Be sure that we are not doing neither read/write after shutdown of the
> >> QEMUFile.
> >> 
> >> Signed-off-by: Juan Quintela <quintela@redhat.com>
> >> ---
> >>  migration/qemu-file.c | 13 +++++++++++++
> >>  1 file changed, 13 insertions(+)
> >> 
> >> diff --git a/migration/qemu-file.c b/migration/qemu-file.c
> >> index 26fb25ddc1..1e5543a279 100644
> >> --- a/migration/qemu-file.c
> >> +++ b/migration/qemu-file.c
> >> @@ -53,6 +53,8 @@ struct QEMUFile {
> >>  
> >>      int last_error;
> >>      Error *last_error_obj;
> >> +    /* has the file has been shutdown */
> >> +    bool shutdown;
> >>  };
> >>  
> >>  /*
> >> @@ -61,6 +63,7 @@ struct QEMUFile {
> >>   */
> >>  int qemu_file_shutdown(QEMUFile *f)
> >>  {
> >> +    f->shutdown = true;
> >>      if (!f->ops->shut_down) {
> >>          return -ENOSYS;
> >>      }
> >> @@ -214,6 +217,9 @@ void qemu_fflush(QEMUFile *f)
> >>          return;
> >>      }
> >>  
> >> +    if (f->shutdown) {
> >> +        return;
> >> +    }
> >
> > OK, I did wonder if you need to free the iovec.
> 
> I will think about this one.
> 
> >>      if (f->iovcnt > 0) {
> >>          expect = iov_size(f->iov, f->iovcnt);
> >>          ret = f->ops->writev_buffer(f->opaque, f->iov, f->iovcnt, f->pos,
> >> @@ -328,6 +334,10 @@ static ssize_t qemu_fill_buffer(QEMUFile *f)
> >>      f->buf_index = 0;
> >>      f->buf_size = pending;
> >>  
> >> +    if (f->shutdown) {
> >> +        return 0;
> >> +    }
> >
> > I also wondered if perhaps an error would be reasonable here; but I'm
> > not sure what a read(2) does after a shutdown(2).
> 
> A fast google shows that it is .... implementation dependant.  And
> worse, only really works for sockets.

Yeh, so our main reason for using it is for hung sockets; in particular,
if a machine just disappears, then you get a many-minute hang waiting
for TCP to timeout.  Using 'shutdown(2)' means you can migrate_cancel
even in that situation.  The same thing happens when you're using
sockets in both directions, if you get an error on one direction you can
shutdown(2) the other direction so you know any thread doesn't get stuck
on it.

Dave

> 
> > Still,
> >
> >
> > Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> 
> Thanks.
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2019-12-18 15:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18  5:04 [PATCH 0/4] Fix multifd + cancel + multifd Juan Quintela
2019-12-18  5:04 ` [PATCH 1/4] qemu-file: Don't do IO after shutdown Juan Quintela
2019-12-18 12:27   ` Dr. David Alan Gilbert
2019-12-18 14:35     ` Juan Quintela
2019-12-18 15:24       ` Dr. David Alan Gilbert [this message]
2019-12-29 18:20     ` Juan Quintela
2020-01-08  9:49     ` Dr. David Alan Gilbert
2020-01-08 12:40       ` Juan Quintela
2020-01-16 10:04         ` Juan Quintela
2019-12-18  5:04 ` [PATCH 2/4] multifd: Make sure that we don't do any IO after an error Juan Quintela
2019-12-18 13:57   ` Dr. David Alan Gilbert
2019-12-18 14:15     ` Juan Quintela
2019-12-18  5:04 ` [PATCH 3/4] migration-test: Make sure that multifd and cancel works Juan Quintela
2019-12-18 16:25   ` Dr. David Alan Gilbert
2019-12-29 18:27     ` Juan Quintela
2019-12-18  5:04 ` [PATCH 4/4] migration: Make sure that we don't call write() in case of error Juan Quintela
2019-12-18 16:33   ` 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=20191218152406.GH3707@work-vm \
    --to=dgilbert@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thuth@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 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).