qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: peterx@redhat.com
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: peterx@redhat.com, Fabiano Rosas <farosas@suse.de>
Subject: [PULL 30/34] migration/multifd: Unify multifd and TLS connection paths
Date: Thu,  8 Feb 2024 11:05:24 +0800	[thread overview]
Message-ID: <20240208030528.368214-31-peterx@redhat.com> (raw)
In-Reply-To: <20240208030528.368214-1-peterx@redhat.com>

From: Fabiano Rosas <farosas@suse.de>

During multifd channel creation (multifd_send_new_channel_async) when
TLS is enabled, the multifd_channel_connect function is called twice,
once to create the TLS handshake thread and another time after the
asynchrounous TLS handshake has finished.

This creates a slightly confusing call stack where
multifd_channel_connect() is called more times than the number of
channels. It also splits error handling between the two callers of
multifd_channel_connect() causing some code duplication. Lastly, it
gets in the way of having a single point to determine whether all
channel creation tasks have been initiated.

Refactor the code to move the reentrancy one level up at the
multifd_new_send_channel_async() level, de-duplicating the error
handling and allowing for the next patch to introduce a
synchronization point common to all the multifd channel creation,
regardless of TLS.

Note that the previous code would never fail once p->c had been set.
This patch changes this assumption, which affects refcounting, so add
comments around object_unref to explain the situation.

Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20240206215118.6171-6-farosas@suse.de
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 migration/multifd.c | 83 ++++++++++++++++++++++-----------------------
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/migration/multifd.c b/migration/multifd.c
index cf865edba0..3db18dc79e 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -869,30 +869,7 @@ out:
     return NULL;
 }
 
-static bool multifd_channel_connect(MultiFDSendParams *p,
-                                    QIOChannel *ioc,
-                                    Error **errp);
-
-static void multifd_tls_outgoing_handshake(QIOTask *task,
-                                           gpointer opaque)
-{
-    MultiFDSendParams *p = opaque;
-    QIOChannel *ioc = QIO_CHANNEL(qio_task_get_source(task));
-    Error *err = NULL;
-
-    if (!qio_task_propagate_error(task, &err)) {
-        trace_multifd_tls_outgoing_handshake_complete(ioc);
-        if (multifd_channel_connect(p, ioc, &err)) {
-            return;
-        }
-    }
-
-    trace_multifd_tls_outgoing_handshake_error(ioc, error_get_pretty(err));
-
-    multifd_send_set_error(err);
-    multifd_send_kick_main(p);
-    error_free(err);
-}
+static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque);
 
 static void *multifd_tls_handshake_thread(void *opaque)
 {
@@ -900,7 +877,7 @@ static void *multifd_tls_handshake_thread(void *opaque)
     QIOChannelTLS *tioc = QIO_CHANNEL_TLS(p->c);
 
     qio_channel_tls_handshake(tioc,
-                              multifd_tls_outgoing_handshake,
+                              multifd_new_send_channel_async,
                               p,
                               NULL,
                               NULL);
@@ -920,6 +897,10 @@ static bool multifd_tls_channel_connect(MultiFDSendParams *p,
         return false;
     }
 
+    /*
+     * Ownership of the socket channel now transfers to the newly
+     * created TLS channel, which has already taken a reference.
+     */
     object_unref(OBJECT(ioc));
     trace_multifd_tls_outgoing_handshake_start(ioc, tioc, hostname);
     qio_channel_set_name(QIO_CHANNEL(tioc), "multifd-tls-outgoing");
@@ -936,18 +917,7 @@ static bool multifd_channel_connect(MultiFDSendParams *p,
                                     QIOChannel *ioc,
                                     Error **errp)
 {
-    trace_multifd_set_outgoing_channel(
-        ioc, object_get_typename(OBJECT(ioc)),
-        migrate_get_current()->hostname);
-
-    if (migrate_channel_requires_tls_upgrade(ioc)) {
-        /*
-         * tls_channel_connect will call back to this
-         * function after the TLS handshake,
-         * so we mustn't call multifd_send_thread until then
-         */
-        return multifd_tls_channel_connect(p, ioc, errp);
-    }
+    qio_channel_set_delay(ioc, false);
 
     migration_ioc_register_yank(ioc);
     p->registered_yank = true;
@@ -959,24 +929,51 @@ static bool multifd_channel_connect(MultiFDSendParams *p,
     return true;
 }
 
+/*
+ * When TLS is enabled this function is called once to establish the
+ * TLS connection and a second time after the TLS handshake to create
+ * the multifd channel. Without TLS it goes straight into the channel
+ * creation.
+ */
 static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
 {
     MultiFDSendParams *p = opaque;
     QIOChannel *ioc = QIO_CHANNEL(qio_task_get_source(task));
     Error *local_err = NULL;
+    bool ret;
 
     trace_multifd_new_send_channel_async(p->id);
-    if (!qio_task_propagate_error(task, &local_err)) {
-        qio_channel_set_delay(ioc, false);
-        if (multifd_channel_connect(p, ioc, &local_err)) {
-            return;
-        }
+
+    if (qio_task_propagate_error(task, &local_err)) {
+        ret = false;
+        goto out;
+    }
+
+    trace_multifd_set_outgoing_channel(ioc, object_get_typename(OBJECT(ioc)),
+                                       migrate_get_current()->hostname);
+
+    if (migrate_channel_requires_tls_upgrade(ioc)) {
+        ret = multifd_tls_channel_connect(p, ioc, &local_err);
+    } else {
+        ret = multifd_channel_connect(p, ioc, &local_err);
     }
 
+    if (ret) {
+        return;
+    }
+
+out:
     trace_multifd_new_send_channel_async_error(p->id, local_err);
     multifd_send_set_error(local_err);
     multifd_send_kick_main(p);
-    object_unref(OBJECT(ioc));
+    if (!p->c) {
+        /*
+         * If no channel has been created, drop the initial
+         * reference. Otherwise cleanup happens at
+         * multifd_send_channel_destroy()
+         */
+        object_unref(OBJECT(ioc));
+    }
     error_free(local_err);
 }
 
-- 
2.43.0



  parent reply	other threads:[~2024-02-08  3:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08  3:04 [PULL 00/34] Migration staging patches peterx
2024-02-08  3:04 ` [PULL 01/34] migration: prevent migration when VM has poisoned memory peterx
2024-02-08  3:04 ` [PULL 02/34] migration/multifd: Drop stale comment for multifd zero copy peterx
2024-02-08  3:04 ` [PULL 03/34] migration/multifd: multifd_send_kick_main() peterx
2024-02-08  3:04 ` [PULL 04/34] migration/multifd: Drop MultiFDSendParams.quit, cleanup error paths peterx
2024-02-08  3:04 ` [PULL 05/34] migration/multifd: Postpone reset of MultiFDPages_t peterx
2024-02-08  3:05 ` [PULL 06/34] migration/multifd: Drop MultiFDSendParams.normal[] array peterx
2024-02-08  3:05 ` [PULL 07/34] migration/multifd: Separate SYNC request with normal jobs peterx
2024-02-08  3:05 ` [PULL 08/34] migration/multifd: Simplify locking in sender thread peterx
2024-02-08  3:05 ` [PULL 09/34] migration/multifd: Drop pages->num check " peterx
2024-02-08  3:05 ` [PULL 10/34] migration/multifd: Rename p->num_packets and clean it up peterx
2024-02-08  3:05 ` [PULL 11/34] migration/multifd: Move total_normal_pages accounting peterx
2024-02-08  3:05 ` [PULL 12/34] migration/multifd: Move trace_multifd_send|recv() peterx
2024-02-08  3:05 ` [PULL 13/34] migration/multifd: multifd_send_prepare_header() peterx
2024-02-08  3:05 ` [PULL 14/34] migration/multifd: Move header prepare/fill into send_prepare() peterx
2024-02-08  3:05 ` [PULL 15/34] migration/multifd: Forbid spurious wakeups peterx
2024-02-08  3:05 ` [PULL 16/34] migration/multifd: Split multifd_send_terminate_threads() peterx
2024-02-08  3:05 ` [PULL 17/34] migration/multifd: Change retval of multifd_queue_page() peterx
2024-02-08  3:05 ` [PULL 18/34] migration/multifd: Change retval of multifd_send_pages() peterx
2024-02-08  3:05 ` [PULL 19/34] migration/multifd: Rewrite multifd_queue_page() peterx
2024-02-08  3:05 ` [PULL 20/34] migration/multifd: Cleanup multifd_save_cleanup() peterx
2024-02-08  3:05 ` [PULL 21/34] migration/multifd: Cleanup multifd_load_cleanup() peterx
2024-02-08  3:05 ` [PULL 22/34] migration/multifd: Stick with send/recv on function names peterx
2024-02-08  3:05 ` [PULL 23/34] migration/multifd: Fix MultiFDSendParams.packet_num race peterx
2024-02-08  3:05 ` [PULL 24/34] migration/multifd: Optimize sender side to be lockless peterx
2024-02-08  3:05 ` [PULL 25/34] migration: Fix logic of channels and transport compatibility check peterx
2024-02-08  3:05 ` [PULL 26/34] migration/multifd: Join the TLS thread peterx
2024-02-10  9:18   ` Michael Tokarev
2024-02-10  9:30     ` Michael Tokarev
2024-02-14 13:27       ` Fabiano Rosas
2024-02-14 13:58         ` Michael Tokarev
2024-02-15 13:24           ` Fabiano Rosas
2024-02-08  3:05 ` [PULL 27/34] migration/multifd: Remove p->running peterx
2024-02-08  3:05 ` [PULL 28/34] migration/multifd: Move multifd_send_setup error handling in to the function peterx
2024-02-08  3:05 ` [PULL 29/34] migration/multifd: Move multifd_send_setup into migration thread peterx
2024-02-08  3:05 ` peterx [this message]
2024-02-08  3:05 ` [PULL 31/34] migration/multifd: Add a synchronization point for channel creation peterx
2024-02-08  3:05 ` [PULL 32/34] tests/migration-test: Stick with gicv3 in aarch64 test peterx
2024-02-08  3:05 ` [PULL 33/34] ci: Remove tag dependency for build-previous-qemu peterx
2024-02-08  3:05 ` [PULL 34/34] ci: Update comment for migration-compat-aarch64 peterx
2024-02-09 16:14 ` [PULL 00/34] Migration staging patches Peter Maydell

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=20240208030528.368214-31-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=farosas@suse.de \
    --cc=peter.maydell@linaro.org \
    --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 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).