From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a135e80f52-3c495685-5942-465a-a4cc-a5a2c1e5d023-000000@eu-central-1.amazonses.com> Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazon11022095.outbound.protection.outlook.com [52.101.66.95]) by lore.virtuozzo.com (Postfix) with ESMTPS id D9A18802A5 for ; Tue, 13 Oct 2026 15:36:06 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OxXvcA0IEd3SdSiDPNRCztn3rAx4W8GaQHq83h3yUdClxxgHZYYqaFcLI3iNYSxjYrx4SLhSoSdPEPRmVTyBwb335H5MO6sDb14gKnRlcuoCr9ESOLQwlAL0mW4gfkPnJE0/NHUXXnX/d0pBXdiNrXNdX0HgvZ3xXyU7+LeGuzUGUCajhUrL6oLN2P3l+xlQ9gbZA1Bal46jJ2AXWv40rRtRRQaNqOg/OBzQr/qTJ7ObhoaH5aBCp2CU7MUiL+oVGaHofYiDUR7gfz8+Wu0MM/yj3L5Y2joramXQdlI59qy7Jgxq8EdEi14+JU4ecBnRMzMy5q9MCmfn6a2TDD1BMQ== 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=ZfE/KIeVd2jw/LsZLzOetwTuAmDPtr5qxyfB8U6Ire0=; b=RvQOR2k7zwRhtEnDzortamgLdYyYzlbtt/aWh4uMSio0n11tEZotNHTnkmzYZfwNYSnIuvH4V6RujusOErV5vcw5nwhS7NTrzvSriKBsZHaQufJ3dAB92Ww4yfREPbsVYbltIKN66wY9cRpkzSz8WyDkD+IY3o/5Yp2e6p7ktrkBetOzKVErVgkRiqnpOSAlLz8yAGZjkdfsmiNa0WIlqEPR/UtCq1X7zWgKicwNUvbWTCTvL6N1EmAM1yHeAYM5dDXgAO+LQ29Sq4XbJ8by5Vw1oeJjBtpYtfvr8n5K32FIKIpLIKA9o7/5NgwhwMmALhZsTpJBEasEYzK29MeTyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.6) 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=ZfE/KIeVd2jw/LsZLzOetwTuAmDPtr5qxyfB8U6Ire0=; b=nlUsitlOdK8z1ZY3DvGqrYdRNFffxINduB/wfaUA4m55SReg92AiwhWZc2hOFqYdUAj4UxUXAyO+zCpgeVhFJehhyL3JUKmKZGX3EABI89wHkZE2TKYH2gaLMaVm+aV3WHt5a4RdtoFVEceBkJIOCJZDiz/JpU0iub9WgpN196k= Received: from AS9PR04CA0077.eurprd04.prod.outlook.com (2603:10a6:20b:48b::13) by VI3PR08MB217650.eurprd08.prod.outlook.com (2603:10a6:800:37a::19) 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:36:04 +0000 Received: from AM2PEPF00070CF2.eurprd02.prod.outlook.com (2603:10a6:20b:48b:cafe::af) by AS9PR04CA0077.outlook.office365.com (2603:10a6:20b:48b::13) 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:36:03 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.6) 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.6 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.6; helo=b224-6.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-6.smtp-out.eu-central-1.amazonses.com (69.169.224.6) by AM2PEPF00070CF2.mail.protection.outlook.com (10.167.242.4) 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:36:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791905763; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=SE/F4t5AEddlK4QP9mpGtmiL7D9iZ6YRaQfhUqLSVZQ=; b=mCB0B9OKARwWu+a4ZgozyXx54L/LrYRJynlZaXzvZtulIZtC0jY+6etLwcuCEdn6 ZzgTuJy//uvzhqI1KF8ptJKKvuJumiAUaCCbr6yn5uVQYrO/2gS+iEljD7HBy3wWXat DFYW8B3QR5izNTA0y7HrTkC56btf04YA+CUqKFnBkP043H0dWe9+HA7BTynKoUGvkNu MG+mwxgrDVsizk+tJi7gkXh68FjNLZ4+CBHUcYf4UdSAl/g9SMBZ6C7sHorjx1DYHi+ JS6A9pL/bY4Nh8fqIIWwY720R2mO66B/WgR2pgZnqeqY+j6Gi6zdDsbhbL2GQlVLrMG NeM0ObZh9A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791905763; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=SE/F4t5AEddlK4QP9mpGtmiL7D9iZ6YRaQfhUqLSVZQ=; b=EnNIh+9gR8FfBCVnsFNVpuInHeEhgf9yr9vT0wfttmKAC2fBPsRt7OT0MI3jGiHN I02oM+5hDwkF5kmAzWqG7IJ85K8HEsCWocVO8XLJTcsYzcBN9ws77+tjQQ/uS8aUg6C KBJ3IID3AyIWPITQ3qAJ/fxR+pus/K1B1PPDpIZw= Message-ID: <010701a135e80f52-3c495685-5942-465a-a4cc-a5a2c1e5d023-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v2 09/24] migration: Fix regression of passing error_fatal into vmstate_load_state() To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261013-vfio_v1-v2-9-433455c0a294@virtuozzo.com> References: <20261013-vfio_v1-v2-0-433455c0a294@virtuozzo.com> <20261013-vfio_v1-v2-9-433455c0a294@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2026 15:36:03 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.13-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM2PEPF00070CF2:EE_|VI3PR08MB217650:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5f3b66ba-0cd8-4a57-91e5-08df293fb0dc 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|9140799003|48200799018|376014|32142699015|61400799027|4113699003|5113699003|16102099003|22082099003|18002099003|10067099003|13003099007|55112099003|4143699003|261009223027099003|56012099006|5063699009; X-Microsoft-Antispam-Message-Info: Sfw48rsUSIstYp4As687PFChtYeIiwvnDiGHP9RYwjOFsJkCIrshTyiGBDcCiIz6ttw7lyp9VJBbte/oYkR9PqXp5Dn42NJuGljIzilpAgK8tOwC1PTbVji/xp3Q+sQDILqQd96lK3/8Qriw24tfhZJwSP7YqbFNKe4Bfy5HDlKuSQKEQahhjQpOt29RLZ4eky3IjjLVVq+17wz7myfpZZEUtHH3x1O28l/dADZ6G6ziWxmfKY+IJ+lzAkgwUPXIQ7C39YkWH/uM/g0B0+UFYepeUeZh3wCvUtDn+C4p5sZDkrsYk1PayRP6Ydz0TApR3VOtGLkIHj4lX2AyLV+3L1OtAFuBx9X4jD+21SnBd3mv5lNGqGGX4M4T/h2H/Dems1r9psbhfTeb2xBpEKhT3EVREZgVPR4dKO7raluxyOucEb+sr5MGZTBaF8A7QMUY9kSP5YI6nASUfvKkM+qB6ltBB/UHqS7oz+QIWkhp9B8kHkZjT0eGYR5HtHN4hwj9mwZ4HqBkPXQbEWBz/eeqTNKF6mNBJYh/x/9OrjCjhP5RHJV8ylwEBkGpLdZ8dYZGGHk2c6lFIC+vP265zz8ABUEr6cltxjEAIvHowmsc3PrkKRXIFN+y8e8Eddh6/zoTI975YwEA4TPI1pxNpgZFMx789kPPTt72IFSeZkZkslVapa/fy2FHpUuStBzG0kWfWD1YXlF1Xb8FGjCSgXuP2SlCkOMkB06YTA2y0SbEMYK4bakDaDxvq8DgR+MllG1iZUGavJFpi7feyKRQhieKBMzmF2MT6m2YTpfSsJMb8cd/xwIuCdU6c99jmEW+nR5D+6WB7ihom41kws655sSiamMF5NsZscJBVTZyNbjex2Yy9zNCZn/waX+X2SYG7Et/ X-Forefront-Antispam-Report: CIP:69.169.224.6;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-6.smtp-out.eu-central-1.amazonses.com;PTR:b224-6.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(9140799003)(48200799018)(376014)(32142699015)(61400799027)(4113699003)(5113699003)(16102099003)(22082099003)(18002099003)(10067099003)(13003099007)(55112099003)(4143699003)(261009223027099003)(56012099006)(5063699009);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +BfV1nuK0gvCJguIzYceHEQ3DBJiojKup79x4STwZadxWIL1f2b+M5bmg5kbjh1pVSa2eYSF+E3zaPe74Ni/3aEpaJUkhxJPWYAWGcaVisJIEr0R0Gj3/qvvAcbHz7CTU54n35LZcOL/MMlQ8rf+NKA0jK66KdETlpxIpdSPq5SPvGmb2dMsMNk+2Ee0fKUjZq4xvEFj6BrMIC7JWWSt/GGX7AB4G2/7PNaVZv2XpzyD1E3l8i8MrtXKXlxZdhY0bKXMXwmmGeb/jWhut14j0ldNYi/Mw03/0GzjlVngYUahqXj1OPc1u5OQKqd/fAXHLKutR5GrIoTehkZsNQ371yxc27takBX+NIElqJrf3msCpJV9nxfOshT0f28N+n7JiL6cgl1qtIK5TKYxzO9a52ida6g2SWJo6x2UxVJasxD43+YBs+kMBvZvPzOrcxmB X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 15:36:03.6037 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f3b66ba-0cd8-4a57-91e5-08df293fb0dc X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF2.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI3PR08MB217650 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] migration: vmstate save/load callers only report Error when ret < 0 -- Subject: Re: [PATCH] migration: Fix regression of passing error_fatal into = vmstate_load_state() commit 7359b43733a10dec8030b1d9e924f7eb62045b03 Author: Arun Menon migration: Fix regression of passing error_fatal into vmstate_load_state() This patch replaces &error_fatal with a local Error object in the callers of vmstate_save_state() and vmstate_load_state(). It reports the error with error_report_err() when the call fails, and returns the result where the caller can use it. Link: https://lore.kernel.org/r/20251028-solve_error_fatal_regression-v2-1-= dab24c808a28@redhat.com > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > --- a/hw/pci/pci.c > +++ b/hw/pci/pci.c [ ... ] > void pci_device_save(PCIDevice *s, QEMUFile *f) > { > + Error *local_err =3D NULL; > + int ret; > + > /* Clear interrupt status bit: it is implicit > * in irq_state which we are saving. > * This makes us compatible with old devices > * which never set or clear this bit. */ > s->config[PCI_STATUS] &=3D ~PCI_STATUS_INTERRUPT; > - vmstate_save_state(f, &vmstate_pci_device, s, NULL, &error_fatal); > + ret =3D vmstate_save_state(f, &vmstate_pci_device, s, NULL, &local_e= rr); > + if (ret < 0) { > + error_report_err(local_err); > + } [Severity: Low] This is a speculative concern, but the same pattern appears in all the new callers, so I am raising it once here. vmstate_save_state_v() treats any nonzero return as a failure, for example in the pre_save, post_save and put paths: migration/vmstate.c:vmstate_save_state_v() { ... if (ret) { error_prepend(errp, "Save of field %s/%s failed: ", ... ... return ret; } ... } The new callers only report the Error when ret < 0. These callers are pci_device_save(), virtio_save() (final subsection save), virtio_gpu_save(), virtio_ccw_save_config(), vscsi_save_request(), virtio_mmio_save_extra_state() and virtio_pci_save_extra_state(). If a callback ever returned a positive nonzero value, would local_err be allocated but neither reported nor freed? The void wrappers would also silently ignore the failure, and virtio_save() and virtio_gpu_save() would return the positive value unchanged. Before this patch, error_fatal would have exited on any nonzero return. The load-side callers have the same exposure through pre_load() (returned as-is) and post_load(). [ ... ] > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c > --- a/hw/virtio/virtio.c > +++ b/hw/virtio/virtio.c [ ... ] > if (vdc->vmsd) { > - int ret =3D vmstate_save_state(f, vdc->vmsd, vdev, NULL, &local_= err); > + ret =3D vmstate_save_state(f, vdc->vmsd, vdev, NULL, &local_err); > if (ret) { > error_report_err(local_err); > return ret; > @@ -3069,7 +3069,11 @@ int virtio_save(VirtIODevice *vdev, QEMUFile *f) > } > =20 > /* Subsections */ > - return vmstate_save_state(f, &vmstate_virtio, vdev, NULL, &error_fat= al); > + ret =3D vmstate_save_state(f, &vmstate_virtio, vdev, NULL, &local_er= r); > + if (ret < 0) { > + error_report_err(local_err); > + } > + return ret; > } [Severity: Low] Within virtio_save(), the vdc->vmsd save a few lines earlier checks "if (ret)", while this final subsection save checks "if (ret < 0)". Should the two checks be consistent? With "ret < 0", a positive return from vmstate_save_state() leaves local_err unreported and unfreed, and virtio_save() returns the positive value. The later series commit "migration: vmstate_save_state_v: fix double error_setg" does not appear to address this. It sets an Error in the put branch only when ret < 0, but the following "if (ret)" block still calls error_prepend(errp, ...). Could a positive return from a put callback then reach error_prepend() with *errp still NULL when a caller passes &local_err, as these callers now do? The callers are unchanged at the end of that series. In practice callbacks conventionally return negative errnos, so this is likely a cold path. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261013-vfio= _v1-v2-0-433455c0a294@virtuozzo.com?part=3D9