From: Juan Quintela <quintela@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
Jiang Jiacheng <jiangjiacheng@huawei.com>,
Peter Xu <peterx@redhat.com>, Leonardo Bras <leobras@redhat.com>
Subject: Re: [PATCH 2/3] migration/multifd: Protect accesses to migration_threads
Date: Wed, 07 Jun 2023 10:26:09 +0200 [thread overview]
Message-ID: <87y1kvoezi.fsf@secure.mitica> (raw)
In-Reply-To: <20230606144551.24367-3-farosas@suse.de> (Fabiano Rosas's message of "Tue, 6 Jun 2023 11:45:50 -0300")
Fabiano Rosas <farosas@suse.de> wrote:
> This doubly linked list is common for all the multifd and migration
> threads so we need to avoid concurrent access.
>
> Add a mutex to protect the data from concurrent access. This fixes a
> crash when removing two MigrationThread objects from the list at the
> same time during cleanup of multifd threads.
>
> To avoid destroying the mutex before the last element has been
> removed, move calls to qmp_migration_thread_remove so they run before
> multifd_save_cleanup joins the threads.
>
> Fixes: 671326201d ("migration: Introduce interface query-migrationthreads")
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
I agree with Peter here. Why don't you have to protect the walking?
> ---
> migration/migration.c | 5 ++++-
> migration/multifd.c | 3 ++-
> migration/threadinfo.c | 19 ++++++++++++++++++-
> migration/threadinfo.h | 5 +++--
> 4 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index e731fc98a1..b3b8345eb2 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1146,6 +1146,7 @@ static void migrate_fd_cleanup(MigrationState *s)
> qemu_mutex_lock_iothread();
>
> multifd_save_cleanup();
> + qmp_migration_threads_cleanup();
I think I will spare this one as the mutex is static, so we are not
winning any memory back.
> }
>
> trace_migration_thread_after_loop();
> + qmp_migration_threads_remove(thread);
> migration_iteration_finish(s);
I can understand moving it here, but why before migration_iteration_finish?
> object_unref(OBJECT(s));
> rcu_unregister_thread();
> - qmp_migration_threads_remove(thread);
> return NULL;
> }
> + qmp_migration_threads_remove(thread);
> +
> qemu_mutex_lock(&p->mutex);
> p->running = false;
> qemu_mutex_unlock(&p->mutex);
>
> rcu_unregister_thread();
> - qmp_migration_threads_remove(thread);
> trace_multifd_send_thread_end(p->id, p->num_packets, p->total_normal_pages);
>
> return NULL;
Here it looks like the right place.
> +#include "qemu/osdep.h"
> +#include "qemu/queue.h"
> +#include "qemu/lockable.h"
> #include "threadinfo.h"
Ouch, it missed Markus cleanup. Thanks.
For the rest it looks good.
Later, Juan.
next prev parent reply other threads:[~2023-06-07 8:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 14:45 [PATCH 0/3] migration: Fix multifd cancel test Fabiano Rosas
2023-06-06 14:45 ` [PATCH 1/3] migration/multifd: Rename threadinfo.c functions Fabiano Rosas
2023-06-06 18:38 ` Peter Xu
2023-06-06 19:34 ` Fabiano Rosas
2023-06-06 20:03 ` Peter Xu
2023-06-07 6:30 ` Juan Quintela
2023-06-07 7:56 ` Philippe Mathieu-Daudé
2023-06-06 14:45 ` [PATCH 2/3] migration/multifd: Protect accesses to migration_threads Fabiano Rosas
2023-06-06 18:43 ` Peter Xu
2023-06-07 8:26 ` Juan Quintela [this message]
2023-06-07 12:00 ` Fabiano Rosas
2023-06-07 13:25 ` Peter Xu
2023-06-07 16:58 ` Juan Quintela
2023-06-06 14:45 ` [PATCH 3/3] tests/qtest: Re-enable multifd cancel test Fabiano Rosas
2023-06-07 8:27 ` Juan Quintela
2024-01-08 6:42 ` Peter Xu
2024-01-08 14:26 ` Fabiano Rosas
2024-01-09 2:12 ` Peter Xu
2024-01-09 7:21 ` Thomas Huth
2024-01-09 7:48 ` Peter Xu
2024-01-09 8:44 ` Thomas Huth
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=87y1kvoezi.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=farosas@suse.de \
--cc=jiangjiacheng@huawei.com \
--cc=leobras@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.