From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a135f9cf1b-7caf89c8-3dbd-4d4e-91c8-2c2c150a0dee-000000@eu-central-1.amazonses.com> Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazon11020127.outbound.protection.outlook.com [52.101.84.127]) by lore.virtuozzo.com (Postfix) with ESMTPS id 2AF90802A5 for ; Tue, 13 Oct 2026 15:55:34 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aOg9RI3cky2vbIBmV+O6YEXeQ38M0qVWue5INiRJN1f9jQ0tm+L11TO+MoHPDnQJQ3ON3V2MiNubw4oFCoMCs16BwaybeNyVYBQ6E8MNHRXmOjhCbsxJsPInkgdDn2s1KL0LExaw7FXhOb5VQJDlmGdkMmKnzGpJxc4Pd8LLvw4etUrUiixXOiO4rcq1FJk39pL8FcPWbIEx6kLKUVKHuF29BGHPiPOCw7nh6PSJdyfD1CDZsdcpHAYx3DqDd43Y9c7edWe6Awvvoq893+VTfXm1FtHVh+AgZS8ArjSgUqq4ndeUomyRSvZswzppgPHwEioDSPSBc+8MFXEwkWt+gQ== 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=3LL+IyryJE29HPPlZMV/LMrDxr6EHKN4oouuBCsb9h4=; b=GI8M8vaxV4p+/03gVnBDTu3gnulc+KSF6UXBgAdXp9uyulZi5Swbk+UdU2xx3zTsV+67//q6BFK/PKmyhrcD6Vi8Zl5RJx5uIuCfjmN/Mx1nsiEwjkZSOwe13jNQOPbuG888KW8IqrhaM/16R9Pj47psGj5GpIVnqJEtv9kzyB5Fhv+wm5Cm9qRU82WJt33DWxXjgV359C7Q0WfqW69RCP/jOrNFod4WOZ0II0XH3GoMT8tm+sQaNEP/egtZ4gUjS3X1L/FndyQMLwzTi4phEs3p3xbBDWNU6M71ngEUKM+bsmyI73ZpvoxZ1pnO2ZUMvybS2TgZpWCUYLaw0bQ4dA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LL+IyryJE29HPPlZMV/LMrDxr6EHKN4oouuBCsb9h4=; b=KuDUazpmK4UV2JoCHBa6MzmVQP0+dpg10XOHm2xczNl+XRmaJiKb/EyOqghW4kDk7mG9Hgjk7TCYy35phCaryuCal7CcXOP/kZwciCWePnL6w4Uvz9RZQlnE9wWym9O6gV2iseag66atP05PXLLw7YbF4JYqi8aYOOeLvAjVThc= Received: from AS9PR05CA0144.eurprd05.prod.outlook.com (2603:10a6:20b:497::25) by GVXPR08MB894662.eurprd08.prod.outlook.com (2603:10a6:150:3a3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 15:55:27 +0000 Received: from MAD0EPF000008AF.eurprd04.prod.outlook.com (2603:10a6:20b:497:cafe::ac) by AS9PR05CA0144.outlook.office365.com (2603:10a6:20b:497::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 13 Oct 2026 15:55:27 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by MAD0EPF000008AF.mail.protection.outlook.com (10.167.241.184) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 15:55:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791906926; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=mE7nsB8UW5PZ8kn5793HAiPuISxfndmqlwzRk+lyN5g=; b=0VMNmWi9XVJqhvUzsku408qA0/CHlIiRhwe9zOEVp5UyOB1Ww2oQaz8tgruZ5pMc 5/CMW0GPjiGI9Czqwxh83b5dqpmBzZUJ4WyWQu2LwlU1C+4mm+QV4XslqMnrez6jMYy RYaycUWTNFtu7HR7d9XHrC7XnRqFPBaugxJwKEV2HSGuVzjdX0o6+/r8Q/oA2KukPxd svCRZay2WBoacyhjkE0IQwj0LQhxVU+sWDlETI6EG874jcyHBIq3XTdgSElYNlEMU87 RwUrfX6USb0mRCIGj9FYrqawMgCo2buQA4g6FrIl5eaETMKxdAUjd6ffRvjAvDSNqQ8 Q6+lXkLDiQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791906926; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=mE7nsB8UW5PZ8kn5793HAiPuISxfndmqlwzRk+lyN5g=; b=Sj8kdf/eeCo0KREOEil3wpW0lbmXNs+v5spJ1ItK0ao4chrtelw5diDhv8FWdjcn Ta+hcZtIIo/mgvQb4DitpgFJ6XLqgpgcjauXZWnWHvGx5TF5FHQCpGg0CkYRpAKECVb zrv20z03avQUTBuObLoaIKH1Y1vcYh5dgtuf8JPU= Message-ID: <010701a135f9cf1b-7caf89c8-3dbd-4d4e-91c8-2c2c150a0dee-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v2 21/24] VZ: migration/cpr-exec: abort cpr-exec if memory can't be preserved To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261013-vfio_v1-v2-21-433455c0a294@virtuozzo.com> References: <20261013-vfio_v1-v2-0-433455c0a294@virtuozzo.com> <20261013-vfio_v1-v2-21-433455c0a294@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2026 15:55:26 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.13-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008AF:EE_|GVXPR08MB894662:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 947e4b0e-c2b6-4d6e-e3a2-08df2942664b X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|376014|61400799027|48200799018|9140799003|32142699015|5023799004|56012099006|5063699009|4143699003|261009223027099003|10067099003|55112099003|16102099003|18002099003|5113699003|4113699003|22082099003; X-Microsoft-Antispam-Message-Info: HZYBWMReHXQh7KclJcC/nlcxcr84I2hVRebhuK3KEt9PqT4L8ue1XBVSJgtEANGPvZ+/B0LPmt5Yzzsk7rbzfDuNudaQ9feZ9X0ugqRNK9TE6WHTVSB4Kr2pgd5+UnHUWcknJqSebrtc4qn6DX6IhPBb01WGn2OcIujHls6jby6MqA4KHZP3dFwfe2ckt8W/+fVDfygVdGgR95KeoCVr0IUcldhFKFyUes8rk/nHlhqv2i5y72ohX3oyPoAiR1Kv2lRBAr3e4T42WmOLzNLdfBb0/mq16bXKGhMTVVzSHfCTvkgrgBCMCsZmCBbhsKWs0/HXRWjJ2Fv8MMisfGBZysu+31QWP5grrKPltYNnQxVZcWrVr5L6Hv8vQo6xR4/CEMG9S/nO/iTPKA3RxCOnRI8s/jKAoVOFCHeDr8QwGnQaZ6ziC1UGxPbx3GzQ2tTHF1t17PY8UW6cDFY5j9/DhwSmfQB1k2EW02sAoRfDGZdupUCW6ZH3MT1GoepEkRIn5O9aKw1SBKBb2ThbfEPtH/91lXK/kyjSfPau8PYZbE/xhOsmwg1aHa163ETzts1+yXHxblsxB5Q/mYOHKw4ywK2aLr2aOzQWK3/baowYDSWcLOFerC1wSsR1hawSOAj/e6pT+fW6p6RgU+q0eSmp1wryojLUKn1oUDX79DCO4J/QKJfwSV3mln7LrF0nnHc1dcRV/plWG/hFYia1MTqiyZgLZwKACWVc6Hrg2wBSdVKFTFBd5Swf7zb9QTmyEzhyWYASvjqe2wMCsiDOmz4GaVrGiidgsgeEfE1cO5bBhrk+N/ZGs75Ade/1m0SiZiY+ X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(376014)(61400799027)(48200799018)(9140799003)(32142699015)(5023799004)(56012099006)(5063699009)(4143699003)(261009223027099003)(10067099003)(55112099003)(16102099003)(18002099003)(5113699003)(4113699003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0tWSwN6UtcBXqAx2eOgnixGxBhNxJH7/sYJVYHRBP6jA52UXwmw5GCR+QUTEpr5x5wfbcNcaFxrvPd1esObesItRG9H+JXdWVq7UGLHsWe1c8U1wJnu28KJptV2h1Tj6CeCEWnDbNPyYhyWXtRyRBuO8Loa6TyZc7S5ZaCzYTzVddHWPpu7I9xS9auhS3qbCOE1jsVt7pg+4EXJIcMzjXitCo/kBqdobk5Hdi61DBVOpmo9l7XATq+K2iuOyybKGEqzBnEwm29kl2fe/c1FX61QfM2sFPq3K0YVFSor+SFoLCeWfM3+Ak2W+Vm+ElkmJcH5VLnDrcQuATJuVcxzmIvVrrLdwqIQa+i+H9/bmbQhkZkFSyvYj/PGEbB48DAiF3r+YYu7p7DtNqvpLfaGxjLNKjHhvAszGrVBynfkasqojlZdrUX06pYo93EwZ+R1E X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 15:55:26.9661 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 947e4b0e-c2b6-4d6e-e3a2-08df2942664b X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008AF.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB894662 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Low] migration: preserve_ram() leaks original Error after migrate_set_er= ror() - [Low] migration: cpr-exec fail path leaves RAM read-only after execvp() f= ailure -- commit 02a023bc5ba37bcad09a7328d397c6b940edac14 Author: Andrey Drobyshev VZ: migration/cpr-exec: abort cpr-exec if memory can't be preserved This patch makes cpr_exec_cb() treat a failed MADV_DOEXEC on any saved ramblock as a failed cpr-exec. It jumps to a shared fail: label, which is also reached when execvp() fails. That label restores close-on-exec on the fds and clears MADV_DOEXEC on the ramblocks, so the VM keeps running in the old QEMU. > diff --git a/migration/cpr-exec.c b/migration/cpr-exec.c > index 7b7609e19cd9..cb962ce72529 100644 > --- a/migration/cpr-exec.c > +++ b/migration/cpr-exec.c [ ... ] > @@ -202,7 +215,10 @@ static void cpr_exec_cb(void *opaque) > */ > cpr_exec_preserve_fds(); > =20 > - cpr_walk_ramblock(preserve_ram); > + if (!cpr_walk_ramblock(preserve_ram)) { > + /* preserve_ram() has already reported the error and failed migr= ation */ > + goto fail; > + } [Severity: Low] Does this new goto fail path leak the original Error object? preserve_ram() builds the error like this: error_setg_errno(&err, errno, "MADV_DOEXEC failed on memory region %s:" " addr=3D%p length=3D%zu", name, (void *) ram.addr, ram.length); error_report_err(error_copy(err)); migrate_set_state(&s->state, s->state, MIGRATION_STATUS_FAILED); migrate_set_error(s, err); return false; error_report_err(error_copy(err)) frees only the copy, and migrate_set_error() stores its own error_copy() without taking ownership. No error_free(err) is reached before return false, so the original Error (the struct and its msg string) is never freed. The execvp() failure path in cpr_exec_cb() does call error_free(err) after migrate_set_error(). The leak in preserve_ram() predates this patch, but this patch now relies on that path to handle the failure. Would an error_free(err) before return false in preserve_ram() be appropriate? > if (cpr_ram_rdonly) { > cpr_walk_ramblock(mark_ram_rdonly); > } [ ... ] > @@ -221,15 +237,17 @@ static void cpr_exec_cb(void *opaque) > * or the system is very short on resources. > */ > error_setg_errno(&err, errno, "execvp %s failed", argv[0]); > - g_clear_pointer(&argv, g_strfreev); > - cpr_exec_unpreserve_fds(); > - > error_report_err(error_copy(err)); > migrate_set_state(&s->state, s->state, MIGRATION_STATUS_FAILED); > migrate_set_error(s, err); > error_free(err); > err =3D NULL; > =20 > +fail: > + g_clear_pointer(&argv, g_strfreev); > + cpr_exec_unpreserve_fds(); > + cpr_exec_unpreserve_ram(); > + [Severity: Low] Can the guest be resumed on read-only RAM when execvp() fails? If cpr_ram_rdonly is set, cpr_exec_cb() calls: if (cpr_ram_rdonly) { cpr_walk_ramblock(mark_ram_rdonly); } before execvp(). If execvp() then fails, the code reaches fail:, which clears MADV_DOEXEC and restores close-on-exec, but nothing restores the RAM protection. cpr_ram_restore_rw() exists: void cpr_ram_restore_rw(void) { cpr_walk_ramblock(mark_ram_rw); } but its only caller is system/vl.c, which runs in the new QEMU after a successful exec. The code after the label then runs: if (runstate_is_live(s->vm_old_state)) { vm_start(); } With RAM still PROT_READ, can the first guest write, or a device emulation write into guest memory, raise SIGSEGV and kill the VM? That seems contrary to the commit message's statement that "the VM keeps running in the old QEMU". The preserve_ram() failure path jumps to fail: before mark_ram_rdonly() and vhost_net_cpr_reset_owners() run, so it is not affected. The execvp() failure path is affected. cpr_ram_rdonly is documented as a debug-only option, which limits the exposure. Should the fail: path call cpr_ram_restore_rw() when cpr_ram_rdonly is set? Later patches in the series (the one that takes the vhost-net devices back if exec fails) add a vhost_net_cpr_set_owners() call before the fail: label. None of the later patches in the series restore RAM to read-write on this path. > /* Note, we can go from state COMPLETED to FAILED */ > migration_call_notifiers(MIG_EVENT_PRECOPY_FAILED, NULL); > --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261013-vfio= _v1-v2-0-433455c0a294@virtuozzo.com?part=3D21