From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>, qemu-devel@nongnu.org
Cc: peterx@redhat.com, "Daniel P . Berrangé" <berrange@redhat.com>,
"Juraj Marcin" <jmarcin@redhat.com>
Subject: Re: [PATCH v3 0/2] migration/tls: Graceful shutdowns for main and postcopy channels
Date: Thu, 18 Sep 2025 18:17:37 -0300 [thread overview]
Message-ID: <875xdfv4su.fsf@suse.de> (raw)
In-Reply-To: <20250918203937.200833-1-peterx@redhat.com>
Peter Xu <peterx@redhat.com> writes:
> v3:
> - Patch 1
> - Update qcrypto_tls_session_read() doc to reflect the new retval [Dan]
> - Update commit message to explain the qatomic_read() change [Dan]
> - Patch 2 (old)
> - Dropped for now, more at the end
>
> This is v3 of the series.
>
> Fabiano fixed graceful shutdowns for multifd channels previously:
>
> https://lore.kernel.org/qemu-devel/20250206175824.22664-1-farosas@suse.de/
>
> However we can still see an warning when running preempt unit test on TLS,
> even though migration functionality will not be affected:
>
> QTEST_QEMU_BINARY=./qemu-system-x86_64 ./tests/qtest/migration-test --full -r /x86_64/migration/postcopy/preempt/tls/psk
> ...
> qemu-kvm: Cannot read from TLS channel: The TLS connection was non-properly terminated.
> ...
>
> It turns out this is because the crypto code only passes the ->shutdown
> field into the read function, however that value can change concurrently in
> another thread by a concurrent qio_channel_shutdown().
>
> Patch 1 should fix this issue.
>
> Patch 2 is something I found when looking at this problem, there's no known
> issues I am aware of with them, however I still think they're logically
> flawed, so I post them together here.
>
> Please review, thanks.
>
> ============= ABOUT OLD PATCH 2 ===================
>
> I dropped it for now to unblock almost patch 1, because patch 1 will fix a
> real warning that can be triggered for not only qtest but also normal tls
> postcopy migration.
>
> While I was looking at temporary settings for multifd send iochannels to be
> blocking always, I found I cannot explain how migration_tls_channel_end()
> currently works, because it writes to the multifd iochannels while the
> channels should still be owned (and can be written at the same time?) by
> the sender threads. It sounds like a thread-safety issue, or is it not?
>
IIUC, the multifd channels will be stuck at p->sem because this is the
success path so migration will have already finished when we reach
migration_cleanup(). The ram/device state migration will hold the main
thread until the multifd channels finish transferring.
> Peter Xu (2):
> io/crypto: Move tls premature termination handling into QIO layer
> migration: Make migration_has_failed() work even for CANCELLING
>
> include/crypto/tlssession.h | 10 +++-------
> crypto/tlssession.c | 7 ++-----
> io/channel-tls.c | 21 +++++++++++++++++++--
> migration/migration.c | 3 ++-
> 4 files changed, 26 insertions(+), 15 deletions(-)
next prev parent reply other threads:[~2025-09-18 21:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 20:39 [PATCH v3 0/2] migration/tls: Graceful shutdowns for main and postcopy channels Peter Xu
2025-09-18 20:39 ` [PATCH v3 1/2] io/crypto: Move tls premature termination handling into QIO layer Peter Xu
2025-09-18 20:39 ` [PATCH v3 2/2] migration: Make migration_has_failed() work even for CANCELLING Peter Xu
2025-09-18 21:17 ` Fabiano Rosas [this message]
2025-09-18 21:46 ` [PATCH v3 0/2] migration/tls: Graceful shutdowns for main and postcopy channels Peter Xu
2025-09-19 13:50 ` Fabiano Rosas
2025-09-22 20:18 ` Peter Xu
2025-09-22 21:41 ` Fabiano Rosas
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=875xdfv4su.fsf@suse.de \
--to=farosas@suse.de \
--cc=berrange@redhat.com \
--cc=jmarcin@redhat.com \
--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.