@samitouri / QOSamiQemu / commits / 89f15c1362

migration: Fix rare hang of migration_channel_read_peek()

In an unlikely case, when a migration stream is attached to the destination QEMU and only send <4 bytes to the channel as magic, it's possible that migration_channel_read_peek() may spin forever. Fix it by adding a manual sleep for partial read. Since the path isn't attached to a coroutine, it means when partial read happens, there's yet not much we can do but hang the main thread, it will happen even for len==0 case. It means monitors can hang due to this, either partial read or no data arrived (but connection established). Leave this for later, the hope is this is extremely rare in production. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3889 Reported-by: Feifan Qian <bea1e@proton.me> Cc: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/r/20260812124327.2572363-1-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>

Peter Xu committed Aug 12, 2026 at 08:43 UTC 89f15c1362970150bf5711cdb84b9742c0db0cd8
1 file changed +9 -2
migration/channel.c
+9 -2
@@ -296,9 +296,16 @@ int migration_channel_read_peek(QIOChannel *ioc,
296
297 if (len == buflen) {
298 break;
299 + } else if (len == QIO_CHANNEL_ERR_BLOCK) {
300 + qio_channel_wait_cond(ioc, G_IO_IN);
301 + } else {
302 + /*
303 + * When partially ready, we can't use qio_channel_wait_cond()
304 + * because it will return immediately. Apply a manual wait.
305 + */
306 + assert(!qemu_in_coroutine());
307 + g_usleep(1000);
308 }
300 -
301 - qio_channel_wait_cond(ioc, G_IO_IN);
309 }
310
311 return 0;