From: Juan Quintela <quintela@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Laurent Vivier" <lvivier@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Zhimin Feng" <fengzhimin1@huawei.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: [PULL 07/19] migration/multifd: fix nullptr access in multifd_send_terminate_threads
Date: Mon, 27 Jan 2020 23:33:09 +0100 [thread overview]
Message-ID: <20200127223321.2742-8-quintela@redhat.com> (raw)
In-Reply-To: <20200127223321.2742-1-quintela@redhat.com>
From: Zhimin Feng <fengzhimin1@huawei.com>
If the multifd_send_threads is not created when migration is failed,
multifd_save_cleanup would be called twice. In this senario, the
multifd_send_state is accessed after it has been released, the result
is that the source VM is crashing down.
Here is the coredump stack:
Program received signal SIGSEGV, Segmentation fault.
0x00005629333a78ef in multifd_send_terminate_threads (err=err@entry=0x0) at migration/ram.c:1012
1012 MultiFDSendParams *p = &multifd_send_state->params[i];
#0 0x00005629333a78ef in multifd_send_terminate_threads (err=err@entry=0x0) at migration/ram.c:1012
#1 0x00005629333ab8a9 in multifd_save_cleanup () at migration/ram.c:1028
#2 0x00005629333abaea in multifd_new_send_channel_async (task=0x562935450e70, opaque=<optimized out>) at migration/ram.c:1202
#3 0x000056293373a562 in qio_task_complete (task=task@entry=0x562935450e70) at io/task.c:196
#4 0x000056293373a6e0 in qio_task_thread_result (opaque=0x562935450e70) at io/task.c:111
#5 0x00007f475d4d75a7 in g_idle_dispatch () from /usr/lib64/libglib-2.0.so.0
#6 0x00007f475d4da9a9 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#7 0x0000562933785b33 in glib_pollfds_poll () at util/main-loop.c:219
#8 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:242
#9 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:518
#10 0x00005629334c5acf in main_loop () at vl.c:1810
#11 0x000056293334d7bb in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4471
If the multifd_send_threads is not created when migration is failed.
In this senario, we don't call multifd_save_cleanup in multifd_new_send_channel_async.
Signed-off-by: Zhimin Feng <fengzhimin1@huawei.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
migration/ram.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/migration/ram.c b/migration/ram.c
index 3fd7fdffcf..82c7edb083 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1233,7 +1233,15 @@ static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
trace_multifd_new_send_channel_async(p->id);
if (qio_task_propagate_error(task, &local_err)) {
migrate_set_error(migrate_get_current(), local_err);
- multifd_save_cleanup();
+ /* Error happen, we need to tell who pay attention to me */
+ qemu_sem_post(&multifd_send_state->channels_ready);
+ qemu_sem_post(&p->sem_sync);
+ /*
+ * Although multifd_send_thread is not created, but main migration
+ * thread neet to judge whether it is running, so we need to mark
+ * its status.
+ */
+ p->quit = true;
} else {
p->c = QIO_CHANNEL(sioc);
qio_channel_set_delay(p->c, false);
--
2.24.1
next prev parent reply other threads:[~2020-01-27 22:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 22:33 [PULL 00/19] 10 next patches Juan Quintela
2020-01-27 22:33 ` [PULL 01/19] migration-test: Use g_free() instead of free() Juan Quintela
2020-01-27 22:33 ` [PULL 02/19] multifd: Make sure that we don't do any IO after an error Juan Quintela
2020-01-27 22:33 ` [PULL 03/19] qemu-file: Don't do IO after shutdown Juan Quintela
2020-01-27 22:33 ` [PULL 04/19] migration: Don't send data if we have stopped Juan Quintela
2020-01-27 22:33 ` [PULL 05/19] migration-test: Make sure that multifd and cancel works Juan Quintela
2020-01-27 22:33 ` [PULL 06/19] migration: Create migration_is_running() Juan Quintela
2020-01-27 22:33 ` Juan Quintela [this message]
2020-01-27 22:33 ` [PULL 08/19] ram_addr: Split RAMBlock definition Juan Quintela
2020-01-27 22:33 ` [PULL 09/19] multifd: multifd_send_pages only needs the qemufile Juan Quintela
2020-01-27 22:33 ` [PULL 10/19] multifd: multifd_queue_page " Juan Quintela
2020-01-27 22:33 ` [PULL 11/19] multifd: multifd_send_sync_main " Juan Quintela
2020-01-27 22:33 ` [PULL 12/19] multifd: Use qemu_target_page_size() Juan Quintela
2020-01-27 22:33 ` [PULL 13/19] migration: Make checkpatch happy with comments Juan Quintela
2020-01-27 22:33 ` [PULL 14/19] multifd: Make multifd_save_setup() get an Error parameter Juan Quintela
2020-01-27 22:33 ` [PULL 15/19] multifd: Make multifd_load_setup() " Juan Quintela
2020-01-27 22:33 ` [PULL 16/19] multifd: Add multifd-method parameter Juan Quintela
2020-01-27 22:33 ` [PULL 17/19] multifd: Split multifd code into its own file Juan Quintela
2020-01-27 22:33 ` [PULL 18/19] migration: Simplify get_qlist Juan Quintela
2020-01-27 22:33 ` [PULL 19/19] migration/compress: compress QEMUFile is not writable Juan Quintela
2020-01-28 17:08 ` [PULL 00/19] 10 next patches Peter Maydell
2020-01-28 18:29 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200127223321.2742-8-quintela@redhat.com \
--to=quintela@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fengzhimin1@huawei.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).