qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: peterx@redhat.com, "Daniel P . Berrangé" <berrange@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Juraj Marcin" <jmarcin@redhat.com>
Subject: [PATCH v3 0/2] migration/tls: Graceful shutdowns for main and postcopy channels
Date: Thu, 18 Sep 2025 16:39:35 -0400	[thread overview]
Message-ID: <20250918203937.200833-1-peterx@redhat.com> (raw)

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?

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(-)

-- 
2.50.1



             reply	other threads:[~2025-09-18 20:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 20:39 Peter Xu [this message]
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 ` [PATCH v3 0/2] migration/tls: Graceful shutdowns for main and postcopy channels Fabiano Rosas
2025-09-18 21:46   ` 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=20250918203937.200833-1-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=jmarcin@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 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).