From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11023097.outbound.protection.outlook.com [40.107.159.97]) by lore.virtuozzo.com (Postfix) with ESMTPS id 677CC80BA6 for ; Tue, 20 Oct 2026 16:31:01 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Cw4SH58n0acQKSGRJdwIFi9hbi0TRWbWTsXeDwqZzg0RPxr4AIRPx3Gyuljb7cpxlgdtfhz7bz1cYslHNkV7U0TCbOxSz+XIec/aGlw1gCSSweu2mvc7wcKVKhRCpIxGPf56qAEtsArsW7oCpKpENXsEvjYtgPBTSbiem1Q97P2oqzgJl19WeXL6cptOdR1cHJA/j8vpksPQfgT+xMuiifEYIxtaWEXS/qbx4fMtey6o076j1l8tk2uDmBAo5InrmeFG86TgQID6Te5bDu09YTvC7oNnidiNIMDziUrRe7QWc7lK0cBaDMLaI77Xjn3Q76Wou1BCZvFvhd/FbbLP+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=50Vvkf/ApYcEEtsQToGzv33XhT7v0N7AjBTaDTSNr4I=; b=YB7PEYwO4CdAwoN0Z/HMes9mWAsCXqy0654qFdGelOYKNiqMMBS5BrXHU1V5CMseMW69EoHFSZlqEEW6VzDKATbWcOU0NhgM2P0z3KR5UDjhHkM1vZ6M8IUG1dIcIIF/4vbaMg1BUUqwNVpWxYt+US7RSK5TJFJXGd1KLkfqxMAddczYlH9gmyr1jWGC8uCtkbQP6hgb7XP0Y35oDw8K8kHbqKXyEkCL9Z3e0DoAtvIuGjh5/u4yxbtSNS1pXnrxNbshDSKxf64d7nYg+FsGgX0EcEKYe4aUeTUPKMoIC8D1pHpYuCflX7uzS025F6lCQ0SA7X+dmUQleu1ZzXiNzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=50Vvkf/ApYcEEtsQToGzv33XhT7v0N7AjBTaDTSNr4I=; b=aDzIxrr6oX+Wip3/NEEOkuDHbeJf1PDDKjStSdMzlvUEaY6QzXSbquU32P60k0u7842vTLhwJbjQNVPHkY1V3G3fp94JsdEijDTpaN3umBs8aNriPNSwQmkB4IF/rHKKhem+f3XLwX4VqwWeU5QtZVxLsGPrViUa2KQKWp6RSs+hFBNlPhFgwxlM672iJOOBUblHZpxOftTVaHBWl7OcwoBKWVqeBQULAumxRO8tPWP3dQFar0EG/h/kmreQAP0H0UUzCJu8F+O2IEi5cjKZUvtcOgiStucTFhbO4c/iYf4jn4vtt+fgRez5f20+ZH6IRYm/xYjKdl6G3f0IoEh/BQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from VI0PR08MB10656.eurprd08.prod.outlook.com (2603:10a6:800:20a::12) by AS4PR08MB7553.eurprd08.prod.outlook.com (2603:10a6:20b:4fb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 16:30:59 +0000 Received: from VI0PR08MB10656.eurprd08.prod.outlook.com ([fe80::4e37:b189:ddcd:3dd8]) by VI0PR08MB10656.eurprd08.prod.outlook.com ([fe80::4e37:b189:ddcd:3dd8%7]) with mapi id 15.21.0546.012; Tue, 20 Oct 2026 16:30:59 +0000 From: Andrey Drobyshev Date: Tue, 20 Oct 2026 19:30:59 +0300 Subject: [PATCH QEMU HCI-8.1 v4 19/31] migration: Fix crash on second migration when cancel early Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20261020-vfio_v1-v4-19-83a5668230e5@virtuozzo.com> References: <20261020-vfio_v1-v4-0-83a5668230e5@virtuozzo.com> In-Reply-To: <20261020-vfio_v1-v4-0-83a5668230e5@virtuozzo.com> To: svt-core@virtuozzo.com Cc: Andrey Drobyshev X-Mailer: b4 0.16.0 X-ClientProxiedBy: VIUP296CA0056.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:34b::14) To VI0PR08MB10656.eurprd08.prod.outlook.com (2603:10a6:800:20a::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10656:EE_|AS4PR08MB7553:EE_ X-MS-Office365-Filtering-Correlation-Id: 4cfcdded-3cf8-4e9f-5d77-08df2ec784d8 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|52116014|366016|6133799003|5113699003|10063799003|10067099003|22082099003|18002099003|3023799007|5023799004|261009223027099003|56012099006|38350700014; X-Microsoft-Antispam-Message-Info: fFqyirD8ekV7QR0c021bg4Fnxlrki8LX+YF2F08c0WB74BE6l1VnWNcH/cYhljD/YP/S96rg5e9nV1ODl7RAHW++x6NmrZJfbIzUQunREGMdK7OqSdC3phtT3fbW5DknzuNsHOAbaePL7b2jW1u3lRbwOM/HDiwnrXIKGR6kqNGyCA2mcG2YIeTFD5LsW0Aee0yn+fL/bHqTwGO4MPvYNsmwpvEiGJC7RiE6JTDmjFIT5uaAdFZ3enRnq9lctEZ/8CedISrPHeWNaVguNcvBFriTFtVh79iTYc/wLBHbLEy/ZvxvHZktYmLanst30xUPYSZ8BU+MOn8naNbn7eTkRouAx2FOoBjQ8+6GIe/fHpPCrQ46MBkSmpwcjxAFYE0XNmcw3I8c1aeEBzwxU9Hu+7tDazaN68hUEFz8jqlIBq5iT7I/vuexhyuNIARHryBRoWVP3hs2SHH5tKWxjYNTAZD/ZI/sN3mqjQx2K2hqPpwGJNgOhTks2LAfi2mC0UMakvERY3JIsP+3pajm6gdNm0YDyf+VvXc5uF2i79ZulwvN9yOAYGT2gCGldKWtLZfnyz5iU4Sk1Og/Bpx7jtIvazh+W1W+Q76y4RzVflFn21uLsllEdh3KZGHNmY/9D7NKQ0l0YMn3tqP5QcVOkJp3WgW0sws1vaLAWwSVISrPyDA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR08MB10656.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(52116014)(366016)(6133799003)(5113699003)(10063799003)(10067099003)(22082099003)(18002099003)(3023799007)(5023799004)(261009223027099003)(56012099006)(38350700014);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dzN4KzZ4WW5WQmpRY3RMTXA4eFJPRS9NZVlkWkJVbkpHbmtkSTlKTW9SQnN4?= =?utf-8?B?NGhTNkZQZXROMVVzRjRKazlzZS94d2Zlb2IyaDA4Z3VqU2lMdWJUYXJoRnEr?= =?utf-8?B?RW5RMzU2V2w0SVhlYUFpYzZmdkJ1N1M3eVZDaEFld3pZUmluQ1N4M1c3ZVBK?= =?utf-8?B?OEQ4bm0vZC81bWdlNU1vQ3dLbjcxVHlCeG1yM2FGMENLd1RFNlRObWtLTkFx?= =?utf-8?B?cm4yWTBjVW1FYlBkNFRlaHR1M3BZTHhZcmI4ZlpycGZycnJ5RFZ0VUpaZUR2?= =?utf-8?B?MU85RXN2QjU4N0xOY055QVlzUHFzSDV5VDBCcjMxMDZFa1YrT2JWRWxZaGJ1?= =?utf-8?B?L3cxZXpjNEd4bXJ4bmpIR2tWTis4Unpqb2Z5T1JQVGc0S1FJNXVHaEN4YkRk?= =?utf-8?B?aXFIWTFzV0g3S0UyWWxWSGE1eWJVWk5Ub0xEUGYvVmVZSklQSGtUam5RM1FM?= =?utf-8?B?LzVuaGRUSFAwV3prNTA0VUJScWpKdlQzQjRPNDFmTkxzMVZlZHZiNjRscm16?= =?utf-8?B?UnRjYmczTUhyYTB3eFUvWHludkZIUlRZcUlXMTk3NytPWDhlZTRDQ2tNUXBW?= =?utf-8?B?NWVtNUt6M0txWTZiK1FTeUZFZ1hSejF4Qi8ybUVsckpOSlNXNVdTaHo5cUth?= =?utf-8?B?ZGNnaXpHQVZyd3dJRVBFc2ZrRXpreVFYZERnVld2NklsVzJIMHYrMC9TRWlN?= =?utf-8?B?cDBVOVREMS9aUGZqSnRjMUVvdG5FUk4xNGZkUS9pU3lSTTExSzBzR0VQZWFT?= =?utf-8?B?Q3QrdmVtUGJUMkVpVmNOL1d3YkJkY0VRUWkrUk9SV2RYK1dJSmdCb3hBVDdL?= =?utf-8?B?SWE4WHJrYVdGWHZ6QXhyZDg5akN0bG04RHp5UHFRM2RWWVFKdjFLMGdzZlFC?= =?utf-8?B?dDRwRVhPeUh2ZnJHbVhwaENaSVdzNFNJbkdYWUFzWFozV1NiblE5UzM3MGZx?= =?utf-8?B?S0d4WHlzMU5aU21laEZyZDNmS3NBRTJ4dndrNjJ6blp3dGZLUm5PTzgzRDZh?= =?utf-8?B?NFROaWZXQWliWU96ejBoVlpyZ0h5WDhLbytQeGg2ZUJGNFVvbm1NcHlLZ2h2?= =?utf-8?B?cmJ2T21FNGR1Rmt0R3BNenQ3NkgwU2pDUTRIdUVRbUgrTUY4bXJIZjV4YnZa?= =?utf-8?B?SWppRkxCbDBTSTlBb3Y5RnpLZ2hwcHlEL002VzRWSmEvTTRLUTJPQkcwazlB?= =?utf-8?B?c29YTjJxNE1UdFlhanA4SnJleWM1dnVvUWpHTlo3TjVCK1dZby90Ym9PVW10?= =?utf-8?B?dzdMQXhkSld0VEJtNVFYMjA2M1dQT0tuT005dkNqOWlRdURhQTQ2dWREQnFp?= =?utf-8?B?TVhDYVpiZDBJRmdNSWdwTFVJalVNZVNLMkRsdzhPR2piUzZ1MTVROVYxb2JG?= =?utf-8?B?M0FuMEJnN1FQb2lmVXNaeFFuQlRLWkpFcVlrL3BFNGF6UHlTMmpVZW91NE9D?= =?utf-8?B?MU9mMCt0eCtlaitoeUMzK3hBSWZIc3VPengwS01sQk8vclZqakVuck1JanU5?= =?utf-8?B?SFNUclRib3AwbHVYaDZRMXI5V3A1Y2dWdEFUQk9jM21HYXBRRnZCZnJvTXFn?= =?utf-8?B?bTdNRGFTbFN0NHBXQklVczBhWk9tL2pDYUNRNTdsdHpUY05sc0xhSFovRHpR?= =?utf-8?B?elJBOGYzNlE1TzFWakgyWkR0NnppWWl6ZEhaZHViemJsSUVnNWZrZmNQZHNO?= =?utf-8?B?bERtRDBDWUQ3WHlrTldKV0lzeFU3QkNPRkhCNFl2Q1c5T1IyN051bTQ0QjA4?= =?utf-8?B?OE9wdFpYcmZMM0pUdHhzUWRJK1h2WVExR1dnTVdPSU9oSS82UDlUd3BhUzhS?= =?utf-8?B?b0xFeFowWFlEZmhzeHVtV2pxQ0hkenhuc1VvV2hqelZmU1FIbU84cWZSSHp2?= =?utf-8?B?YTVwbGtJcG13MzdoUXE0RnNVWDNtbE15VzVaRk5KcXkxMkR4NmdodHhOQmp5?= =?utf-8?B?a3BMampZN25XRkJqUmNZb3BRRTY0SitDTkpBZUxrMWplV1orc3hISDEyaHox?= =?utf-8?B?K1M4V1M2M1kyeCtoTHM3bUFEQ1FPVTc1STZQczB5Y3FEZy9lY0pVVU1UbDBl?= =?utf-8?B?TjJpWHBNNThBM3NMajNqY2tsTGYrSDZQVG9KeHN6YThPbTlaKy9xSHlOZmor?= =?utf-8?B?bkoxeVVqS25uQ29YOWtsN0dlaTdpUEV2QjY5aVNyQzJTTVE2dXdMU3MwUHEw?= =?utf-8?B?YnNFYStLdWVmcmZRdkxqQldycUpIVXRyV2plTXNBNVloU0lhRGlVNS9CTlRs?= =?utf-8?B?c202NWEweXlDcnMrd09nZVB3YkpFQUY2RzFESmdYL2JzemhLWGlaZjNTcUk0?= =?utf-8?B?M1NzUkxzQ2pSUHN4K0hmNTJOQ3ZrUVY1T3BicHJZSkJZZUNyY3JuZEpFVzFO?= =?utf-8?Q?3h02k5czlcKgrjZg=3D?= X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4cfcdded-3cf8-4e9f-5d77-08df2ec784d8 X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10656.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 16:30:57.2893 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MWVhMfeUDigUnCwNIYS+wpoa6Jd6yeBE6h9LzUX4qYkSCwup5dmSFKd08PLSKvschlxYaQwfI/v8n5pyK8f2LF8J8TMcfEKRcL5GSsk37gQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7553 From: Peter Xu Marc-André reported an issue on QEMU crash when retrying a cancelled migration during early setup phase, see "Link:" for more information, and also easy way to reproduce. This patch is a replacement of the prior fix proposed by not only switching to migration_cleanup(), but also fixing it from CPR side, so that we track hup_source properly to know if src QEMU is waiting or the HUP signal. To put it simple: this chunk of special casing in migration_cancel() should not affect normal migration, but only cpr-transfer migration to cover the small window when the src QEMU is waiting for a HUP signal on cpr channel (so that src QEMU can continue the migration on the main channel). To achieve that, we'll also need to remember to detach the hup_source whenenver invoked: after that point, we should always be able to cleanup the migration. It's not a generic operation to explicitly detach a gsource from its context while in its dispatch() function. But it should be safe, because gsource disptch() will only happen with a boosted refcount for the dispatcher so that the gsource will not be freed until the callback completes. It's also safe to return G_SOURCE_REMOVE after the gsource is detached, as glib will simply ignore the G_SOURCE_REMOVE. One can refer to latest 2.86.5 glib code in g_main_dispatch() for that: https://github.com/GNOME/glib/blob/2.86.5/glib/gmain.c#L3592 When at this, add a bunch of assertions to make sure nothing surprises us. After this patch applied, the 2nd migration will not crash QEMU, instead it'll be in CANCELLING until the socket connection times out (it will take ~2min on my Fedora default kernel). During this process no 2nd migration will be allowed, and after it timed out migration can be restarted. It's because so far we don't have control over socket_connect_outgoing(), or anything yet managed by a task executed in qio_task_run_in_thread(). Speeding up the cancellation to be left for future. I also tested cpr-transfer by only providing cpr channel not the main channel (with -incoming defer), kickoff migration on source, then cancel it on source directly without providing the main channel. It keeps working. I wanted to add an unit test for that but it'll need to refactor current cpr-transfer tests first; let's leave it for later. andrey.drobyshev: This commit was cherry-picked from the upstream commit 4f08b870f8f0, adapted for the hci-dev base, which predates the upstream qmp_migrate() rework: the HUP callback is still qmp_migrate_finish_cb() rather than migration_connect_outgoing_cb(), so the early cpr_transfer_source_destroy() call lands there, ahead of qmp_migrate_finish() and the cpr_state_close() the callback keeps doing itself. Link: https://lore.kernel.org/r/20260417184742.293061-1-marcandre.lureau@redhat.com Reported-by: Marc-André Lureau Tested-by: Fabiano Rosas Reviewed-by: Fabiano Rosas Link: https://lore.kernel.org/r/20260421175820.302795-1-peterx@redhat.com Signed-off-by: Peter Xu --- include/migration/cpr.h | 1 + migration/cpr-transfer.c | 10 ++++++++++ migration/migration.c | 32 ++++++++++++++++++++++++-------- migration/migration.h | 5 +++++ 4 files changed, 40 insertions(+), 8 deletions(-) diff --git a/include/migration/cpr.h b/include/migration/cpr.h index ae441322ff5..4dd397a7c13 100644 --- a/include/migration/cpr.h +++ b/include/migration/cpr.h @@ -80,6 +80,7 @@ QEMUFile *cpr_transfer_input(MigrationChannel *channel, Error **errp); void cpr_transfer_add_hup_watch(MigrationState *s, QIOChannelFunc func, void *opaque); void cpr_transfer_source_destroy(MigrationState *s); +bool cpr_transfer_source_active(MigrationState *s); void cpr_exec_init(void); QEMUFile *cpr_exec_output(Error **errp); diff --git a/migration/cpr-transfer.c b/migration/cpr-transfer.c index 61d5c9dce2b..9defe7bad78 100644 --- a/migration/cpr-transfer.c +++ b/migration/cpr-transfer.c @@ -6,6 +6,7 @@ */ #include "qemu/osdep.h" +#include "qemu/main-loop.h" #include "qapi/clone-visitor.h" #include "qapi/error.h" #include "qapi/qapi-visit-migration.h" @@ -79,6 +80,7 @@ QEMUFile *cpr_transfer_input(MigrationChannel *channel, Error **errp) void cpr_transfer_add_hup_watch(MigrationState *s, QIOChannelFunc func, void *opaque) { + assert(bql_locked()); s->hup_source = qio_channel_create_watch(cpr_state_ioc(), G_IO_HUP); g_source_set_callback(s->hup_source, (GSourceFunc)func, @@ -89,9 +91,17 @@ void cpr_transfer_add_hup_watch(MigrationState *s, QIOChannelFunc func, void cpr_transfer_source_destroy(MigrationState *s) { + assert(bql_locked()); if (s->hup_source) { g_source_destroy(s->hup_source); g_source_unref(s->hup_source); s->hup_source = NULL; } } + +bool cpr_transfer_source_active(MigrationState *s) +{ + /* Whenever the HUP gsource is available, it's active. */ + assert(bql_locked()); + return s->hup_source; +} diff --git a/migration/migration.c b/migration/migration.c index b7db5c94b0d..3732751e66c 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -1661,14 +1661,19 @@ void migration_cancel(void) } /* - * If qmp_migrate_finish has not been called, then there is no path that - * will complete the cancellation. Do it now. + * This is cpr-transfer specific processing. + * + * If this is true, it means cpr-transfer migration is waiting for the + * destination to send HUP event on CPR channel to continue the next + * phase. If so, do the cleanup proactively to avoid get stuck in + * CANCELLING state. */ - if (setup && !s->to_dst_file) { - migrate_set_state(&s->state, MIGRATION_STATUS_CANCELLING, - MIGRATION_STATUS_CANCELLED); - cpr_state_close(); - cpr_transfer_source_destroy(s); + if (cpr_transfer_source_active(s)) { + assert(migrate_mode() == MIG_MODE_CPR_TRANSFER); + assert(setup && !s->to_dst_file); + migration_cleanup(s); + /* Now all things should have been released */ + assert(!cpr_transfer_source_active(s)); } } @@ -2266,11 +2271,22 @@ static gboolean qmp_migrate_finish_cb(QIOChannel *channel, void *opaque) { MigrationAddress *addr = opaque; + MigrationState *s = migrate_get_current(); + + /* + * Detach and release the GSource right after use. We rely on this to + * detect this small cpr-transfer window of "waiting for HUP event". + */ + cpr_transfer_source_destroy(s); qmp_migrate_finish(addr, NULL); cpr_state_close(); - cpr_transfer_source_destroy(migrate_get_current()); + + /* + * This is redundant as we do cpr_transfer_source_destroy() at the + * entry, but it's benign; glib will just skip the detach. + */ return G_SOURCE_REMOVE; } diff --git a/migration/migration.h b/migration/migration.h index a7ea43e925d..ee15ca88461 100644 --- a/migration/migration.h +++ b/migration/migration.h @@ -509,6 +509,11 @@ struct MigrationState { /* Is this a rdma migration */ bool rdma_migration; + /* + * When set, it means cpr-transfer is waiting for the HUP signal from + * destination to continue the 2nd step of migration via the main + * channel. + */ GSource *hup_source; }; -- 2.47.1