qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2 1/1] qemu/migration: fix the double free prob


From: Peter Xu
Subject: Re: [Qemu-block] [PATCH v2 1/1] qemu/migration: fix the double free problem on from_src_file
Date: Wed, 7 Jun 2017 11:29:08 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Jun 06, 2017 at 06:42:18PM +0100, Dr. David Alan Gilbert wrote:
> * Kevin Wolf (address@hidden) 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 <address@hidden>
> > > Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> > > Reviewed-by: Peter Xu <address@hidden>
> > 
> > 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.

Agree.

Does qmp_xen_load_devices_state() needs to call
migration_incoming_state_destroy() after all? Since the latter
function only cleanups MigrationIncomingState and looks like the
former xen code didn't really use it at all.

> 
> > 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 / address@hidden / Manchester, UK

-- 
Peter Xu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]