migration/multifd: Unify multifd and TLS connection paths
authorFabiano Rosas <farosas@suse.de>
Tue, 6 Feb 2024 21:51:17 +0000 (18:51 -0300)
committerPeter Xu <peterx@redhat.com>
Wed, 7 Feb 2024 01:53:18 +0000 (09:53 +0800)
commit2576ae488ef9aa692486157df7d8b410919cd219
treeca8bd9a47baa31389bd857a3bf1dfb9d932c53d1
parentdd904bc13f2af0c605c3fe72f118ea4e27a6610c
migration/multifd: Unify multifd and TLS connection paths

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