* Kevin Wolf (kw...@redhat.com) wrote:
> Am 06.06.2017 um 07:24 hat QingFeng Hao geschrieben:
> > In load_snapshot, mis->from_src_file is freed twice, the first free is by
> > qemu_fclose, the second is by migration_incoming_state_destroy and
> > it causes Illegal instruction exception. The fix is just to remove the
> > first free.
> >
> > This problem is found by qemu-iotests case 068 since commit
> > "660819b migration: shut src return path unconditionally". The error is:
> > 068 1s ... - output mismatch (see 068.out.bad)
> > --- tests/qemu-iotests/068.out 2017-05-06 01:00:26.417270437 +0200
> > +++ 068.out.bad 2017-06-03 13:59:55.360274640 +0200
> > @@ -6,6 +6,8 @@
> > QEMU X.Y.Z monitor - type 'help' for more information
> > (qemu) savevm 0
> > (qemu) quit
> > +./common.config: line 107: 242472 Illegal instruction (core
> > dumped) ( if [ -n "${QEMU_NEED_PID}" ]; then
> > + echo $BASHPID > "${QEMU_TEST_DIR}/qemu-${_QEMU_HANDLE}.pid";
> > +fi; exec "$QEMU_PROG" $QEMU_OPTIONS "$@" )
> > QEMU X.Y.Z monitor - type 'help' for more information
> > -(qemu) quit
> > -*** done
> > +(qemu) *** done
> >
> > Signed-off-by: QingFeng Hao <ha...@linux.vnet.ibm.com>
> > Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > Reviewed-by: Peter Xu <pet...@redhat.com>
>
> Dave, as you only gave R-b rather than merging the patch, should this be
> merged through the block tree?
I'm happy for it to go via block but also happy for it to go via
migration; Juan is mostly doing the migration set at the moment since
they're dominated by his cleanups.
> > diff --git a/migration/savevm.c b/migration/savevm.c
> > index 9c320f59d0..853e14e34e 100644
> > --- a/migration/savevm.c
> > +++ b/migration/savevm.c
> > @@ -2290,7 +2290,6 @@ int load_snapshot(const char *name, Error **errp)
> >
> > aio_context_acquire(aio_context);
> > ret = qemu_loadvm_state(f);
> > - qemu_fclose(f);
> > aio_context_release(aio_context);
> >
> > migration_incoming_state_destroy();
>
> Did we check other callers of migration_incoming_state_destroy()?
>
> For example, qmp_xen_load_devices_state() looks suspicious, too.
Hmm, it looks suspicious in the opposite direction; it never sets
mis->from_src_file as was added by b4b076da into the load_snapshot path.
> I can't tell for postcopy_ram_listen_thread() - commit 660819b didn't
> seem to remove a qemu_fclose() call there, but I can't see one left
> behind either. Was the file leaked before commit 660819b or am I
> missing something?
I don't think there's a problem in the postcopy path, although hmm was
I missing a close before?
Dave
>
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
