Re: [Qemu-devel] [PATCH] migration: fix live migration failure with compression

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Li, Liang Z (liang.z.li@intel.com) wrote:
> > Subject: Re: [PATCH] migration: fix live migration failure with compression
> > 
> > * Liang Li (liang.z.li@intel.com) wrote:
> > > Because of commit 11808bb0c422, which remove some condition checks of
> > > 'f->ops->writev_buffer', 'qemu_put_qemu_file' should be enhanced to
> > > clear the 'f_src->iovcnt', or 'f_src->iovcnt' may exceed the
> > > MAX_IOV_SIZE which will break live migration. This should be fixed.
> > >
> > > Signed-off-by: Liang Li <liang.z.li@intel.com>
> > > Reported-by: Jinshi Zhang <jinshi.c.zhang@intel.com>
> > > ---
> > >  migration/qemu-file.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/migration/qemu-file.c b/migration/qemu-file.c index
> > > bbc565e..e9fae31 100644
> > > --- a/migration/qemu-file.c
> > > +++ b/migration/qemu-file.c
> > > @@ -668,6 +668,7 @@ int qemu_put_qemu_file(QEMUFile *f_des,
> > QEMUFile *f_src)
> > >          len = f_src->buf_index;
> > >          qemu_put_buffer(f_des, f_src->buf, f_src->buf_index);
> > >          f_src->buf_index = 0;
> > > +        f_src->iovcnt = 0;
> > >      }
> > 
> > If you're just using the buf[] in the src, how does it end up incrementing the
> > iovcnt?
> > 
> > Dave
> > 
> > >      return len;
> > >  }
> 
> 'qemu_put_be32' is used to put some data to  an allocated 'f_src'. Before the 11808bb0c422, this operation
> won't increase the 'f_src->iovcnt', there is no issue.
> Commit 11808bb0c422 remove the checking of 'f->ops->writev_buffer',
> now 'qemu_put_be32' will increase 'f_src->iovcnt' and set 'f_src->iov []', once the 'f_src->iovcnt' reach to
> MAX_IOV_SIZE, 'qemu_fflush' will be trigged. Beacause 'f_src' is not writeable, 'qemu_fflsh' will return
> without wrapping around 'f_src->iovcnt' , the following 'qemu_put_be32' on 'f_src' will increase 'f_src->iovcnt'
> and make it exceed MAX_IOV_SIZE, then set 'f_src->iov[]' will corrupt memory.

OK, thanks

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Amit, Peter: I think this is one for 2.7 because I think that's a regression
given that the 11808bb0c422 referenced is after 2.6.

Dave


> Liang
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK