All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Bras <leobras.c@gmail.com>
To: Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Xu <peterx@redhat.com>
Cc: Leonardo Bras <leobras.c@gmail.com>, qemu-devel@nongnu.org
Subject: [PATCH v1 3/4] migration/multifd: Join all multifd threads in order to avoid leaks
Date: Fri, 10 Feb 2023 03:31:44 -0300	[thread overview]
Message-ID: <20230210063145.530952-3-leobras.c@gmail.com> (raw)
In-Reply-To: <20230210063145.530952-1-leobras.c@gmail.com>

Current approach will only join threads that are still running.

For the threads not joined, resources or private memory are always kept in
the process space and never reclaimed before process end, and this risks
serious memory leaks.

This should usually not represent a big problem, since multifd migration
is usually just ran at most a few times, and after it succeeds there is
not much to be done before exiting the process.

Yet still, it should not hurt performance to join all of them.

Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
---
 migration/multifd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/migration/multifd.c b/migration/multifd.c
index 1a445b36f1..7e37a459ed 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -1039,8 +1039,9 @@ void multifd_load_cleanup(void)
              * however try to wakeup it without harm in cleanup phase.
              */
             qemu_sem_post(&p->sem_sync);
-            qemu_thread_join(&p->thread);
         }
+
+        qemu_thread_join(&p->thread);
     }
     for (i = 0; i < migrate_multifd_channels(); i++) {
         MultiFDRecvParams *p = &multifd_recv_state->params[i];
-- 
2.39.1



  parent reply	other threads:[~2023-02-10  6:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  6:31 [PATCH v1 1/4] migration/multifd: Change multifd_load_cleanup() signature and usage Leonardo Bras
2023-02-10  6:31 ` [PATCH v1 2/4] migration/multifd: Remove unnecessary assignment on multifd_load_cleanup() Leonardo Bras
2023-02-10  6:31 ` Leonardo Bras [this message]
2023-02-10  6:31 ` [PATCH v1 4/4] migration/multifd: Move load_cleanup inside incoming_state_destroy Leonardo Bras
2023-02-10  6:33 ` [PATCH v1 1/4] migration/multifd: Change multifd_load_cleanup() signature and usage Leonardo Brás
2023-02-10  6:36 Leonardo Bras
2023-02-10  6:36 ` [PATCH v1 3/4] migration/multifd: Join all multifd threads in order to avoid leaks Leonardo Bras
2023-02-10 12:49   ` Juan Quintela
2023-02-10 17:21   ` Peter Xu

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=20230210063145.530952-3-leobras.c@gmail.com \
    --to=leobras.c@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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 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.