From: Juan Quintela <quintela@redhat.com>
To: Zhimin Feng <fengzhimin1@huawei.com>
Cc: zhang.zhanghailiang@huawei.com, dgilbert@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH] migration/multifd: fix nullptr access in multifd_send_terminate_threads
Date: Fri, 24 Jan 2020 13:47:08 +0100 [thread overview]
Message-ID: <87iml13ttf.fsf@secure.laptop> (raw)
In-Reply-To: <20200110085019.876-1-fengzhimin1@huawei.com> (Zhimin Feng's message of "Fri, 10 Jan 2020 16:50:19 +0800")
Zhimin Feng <fengzhimin1@huawei.com> wrote:
> 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>
prev parent reply other threads:[~2020-01-24 12:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-10 8:50 [PATCH] migration/multifd: fix nullptr access in multifd_send_terminate_threads Zhimin Feng
2020-01-24 12:47 ` Juan Quintela [this message]
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=87iml13ttf.fsf@secure.laptop \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=fengzhimin1@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=zhang.zhanghailiang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.