Message ID | 20200928152024.209894-2-dgilbert@redhat.com |
---|---|
State | New |
Headers | show |
Series | migration queue | expand |
On Mon, Sep 28, 2020 at 04:20:24PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com> > > This reverts commit c02039a6f3730ddcf683a0ba9a175688c6db71a0. > > This is breaking test 068 that does a loadvm twice. This is exactly something I'm afraid of happening... :-( Though for the long term in the future, ideally maybe we should just forbid loadvm for more than once (restarting a QEMU instance won't hurt, afaict, or we really need to be careful on the whole loadvm path, I'm not sure whether there's any other spots that we didn't notice that won't allow reentrance), or we should provide some reset helper, so that we won't only destroy partially in the destroy helper. -- Peter Xu
diff --git a/migration/migration.c b/migration/migration.c index 838ca79f57..aca7fdcd0b 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -238,15 +238,12 @@ void migration_incoming_state_destroy(void) mis->postcopy_remote_fds = NULL; } + qemu_event_reset(&mis->main_thread_load_event); + if (mis->socket_address_list) { qapi_free_SocketAddressList(mis->socket_address_list); mis->socket_address_list = NULL; } - - qemu_event_destroy(&mis->main_thread_load_event); - qemu_sem_destroy(&mis->postcopy_pause_sem_dst); - qemu_sem_destroy(&mis->postcopy_pause_sem_fault); - qemu_mutex_destroy(&mis->rp_mutex); } static void migrate_generate_event(int new_state)