qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: "chenyuhui (A)" <chenyuhui5@huawei.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org
Cc: xuyinghua3@huawei.com, liheng.liheng@huawei.com,
	renxuming@huawei.com, pengyi.pengyi@huawei.com,
	yubihong@huawei.com, zhengchuan@huawei.com, huhao33@huawei.com,
	caozhongwang1@huawei.com, caiqingmu@huawei.com,
	Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH] migrate/multifd: fix coredump when the multifd thread cleanup
Date: Mon, 14 Aug 2023 11:55:46 -0300	[thread overview]
Message-ID: <87h6p1vfkd.fsf@suse.de> (raw)
In-Reply-To: <731ee7bd-8935-7970-e217-888a4199ba95@huawei.com>

"chenyuhui (A)" via <qemu-devel@nongnu.org> writes:

> On 2023/7/26 0:53, Peter Xu wrote:
>> On Tue, Jul 25, 2023 at 04:43:28PM +0800, chenyuhui (A) wrote:
>>> @Peter Xu @Fabiano Rosas
>>> Kindly ping on this.
>> 
>> Ah I see what's missing - please copy maintainer (Juan) for any migration
>> patches, especially multifd ones..  I'm doing that for this one, but I'd
>> suggest you repost with a whole patch and information put into commit msg.
>> 
>> Thanks.
>> 
> Hi, Juan
> This is a patch for migration,please take a look.
>
> From: Yuhui Chen <chenyuhui5@huawei.com>
> Date: Tue, 25 Jul 2023 10:45:48 +0800
> Subject: [PATCH] migrate/multifd: fix coredump when the multifd thread cleanup
>
> There is a coredump while trying to destroy mutex when
> p->running is false but p->mutex is not unlock.
> Make sure all mutexes has been released before destroy them.
>
> Signed-off-by: Yuhui Chen <chenyuhui5@huawei.com>
> ---
>  migration/multifd.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/migration/multifd.c b/migration/multifd.c
> index 3387d8277f..3a085bf3ec 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -521,9 +521,7 @@ void multifd_save_cleanup(void)
>      for (i = 0; i < migrate_multifd_channels(); i++) {
>          MultiFDSendParams *p = &multifd_send_state->params[i];
>
> -        if (p->running) {
> -            qemu_thread_join(&p->thread);
> -        }
> +        qemu_thread_join(&p->thread);
>      }
>      for (i = 0; i < migrate_multifd_channels(); i++) {
>          MultiFDSendParams *p = &multifd_send_state->params[i];

Hi,

I took another look at this and noticed that we're not even holding the
lock in the other threads when accessing p->running.

Also, the save_cleanup() function can be called before
qemu_thread_create(), which means p->thread.thread would have a bogus
value and qemu_thread_join() would abort the QEMU process.

What we need here is to stop setting p->running from inside the thread
altogether. The flag is only effectively protecting the
qemu_thread_join() from being called before the thread's creation. We
can post to sem_sync regardless of the thread state because we only
destroy it a few lines down in the same function. And there's already
p->quit which is being accessed properly and sends the thread out of the
loop.

So I suggest this pattern:

qemu_sem_post(&p->sem_sync);
if (p->running) {
    qemu_thread_join(&p->thread);
    p->running = false;
}

It would also be nice to move the p->running = true closer to the
qemu_thread_create() call at multifd_channel_connect().



      reply	other threads:[~2023-08-14 14:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21  8:18 [PATCH] migrate/multifd: fix coredump when the multifd thread cleanup z00619469 via
2023-06-21 13:24 ` Peter Xu
2023-06-21 14:22 ` Fabiano Rosas
2023-06-26 13:16   ` chenyuhui (A) via
2023-06-27  1:11     ` chenyuhui (A) via
2023-07-25  8:43       ` chenyuhui (A) via
2023-07-25 16:53         ` Peter Xu
2023-07-27  1:46           ` chenyuhui (A) via
2023-08-14 14:55             ` Fabiano Rosas [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=87h6p1vfkd.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=caiqingmu@huawei.com \
    --cc=caozhongwang1@huawei.com \
    --cc=chenyuhui5@huawei.com \
    --cc=huhao33@huawei.com \
    --cc=liheng.liheng@huawei.com \
    --cc=pengyi.pengyi@huawei.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=renxuming@huawei.com \
    --cc=xuyinghua3@huawei.com \
    --cc=yubihong@huawei.com \
    --cc=zhengchuan@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 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).