* Li, Liang Z (liang.z...@intel.com) wrote: > > Subject: Re: [PATCH] migration: fix live migration failure with compression > > > > * Liang Li (liang.z...@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...@intel.com> > > > Reported-by: Jinshi Zhang <jinshi.c.zh...@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 <dgilb...@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 / dgilb...@redhat.com / Manchester, UK
