diff options
| author | Fabiano Rosas <farosas@suse.de> | 2024-02-06 18:51:17 -0300 |
|---|---|---|
| committer | Peter Xu <peterx@redhat.com> | 2024-02-07 09:53:18 +0800 |
| commit | 2576ae488ef9aa692486157df7d8b410919cd219 (patch) | |
| tree | ca8bd9a47baa31389bd857a3bf1dfb9d932c53d1 /chardev/char-parallel.c | |
| parent | dd904bc13f2af0c605c3fe72f118ea4e27a6610c (diff) | |
| download | focaccia-qemu-2576ae488ef9aa692486157df7d8b410919cd219.tar.gz focaccia-qemu-2576ae488ef9aa692486157df7d8b410919cd219.zip | |
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>
Diffstat (limited to 'chardev/char-parallel.c')
0 files changed, 0 insertions, 0 deletions