From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1a1c75c7b-86069160-327b-410d-a9e5-5cce343c76fa-000000@eu-central-1.amazonses.com> Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11020098.outbound.protection.outlook.com [52.101.69.98]) by lore.virtuozzo.com (Postfix) with ESMTPS id 6172A8045D for ; Tue, 3 Nov 2026 14:19:23 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yus4KxZ0nAtGDNOCxGWPvwV4J0kiCY9/s2612GynDncEDK/MuFGyWgZGSD2rRV5Ma5mL5hDxStCgVCjeVtw4qiGzv4rLFC964F/YZYLpQKXKTo/01hD6MgkKzIt65214WfTqE3oxYZrXMrCJ4UU3D1P0b1xHt3EtBB0fv2NEeRxMu3jgHfosl73MzAGPSUNe7LkgEHaYXtj8/AHIdBsLg8zoGWbvLxmt5KzUV4bxBHxkB8gLXHLlRRrzSxkmT5eLc7pOEnDx+Jc8l7wJLsanehX2H+icLPv62iTI08VMbrSPt7Kjw1fkp/9sROxHPtGUFd49izIVSf/wU6Erqf6iHg== 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=JQufZZlfDVWM63HNQPVpudxUGelunquGOejnIRp8fpE=; b=Yv+/Nhs1TmwRYPPz7swcYguXK/qwS25DUBKrFwBVjS52IErF1ysePEMySqa2+t4iZVbWl4wcQHp+VX4tdRVpNHjfL2VVvcAKTkScHep4NH4aAwvBXh+74i+qmDTT192otTV4reeQYre6lwSO8EzGCr8BrteLAlZ2BNW2gTwBiX8nMEkcHF785sUXznU8PKGWi0OLrO3/WumRIV3FRRbYmYo2r2gcDNWcl2qR7OZ6LqCt2KYr1Acloq4zOWHwY0hPOUot7YxWNvLtoPZTfbt+ELLpusrD1vQ1CfFGVOCqb/lxUoCjYk0FZoHESylPHa+mW02daIw9khFd37idm5SJEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) 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=JQufZZlfDVWM63HNQPVpudxUGelunquGOejnIRp8fpE=; b=RH/w+imgF19fGHLik8XXiFNOUrNTZ1a+kJfhX3a/ZjClMDM+Nrc7NpJxLz7F4jIXn/tzqlxYrvmw2Z+dtgow1rIWjd0NgqNHYbnmTpLOYI6Akd57W0J7XtdSooAmH2Ym8cvt1+Llj124fJTniSr+OWx+9jtXVGPYsKxuDkDVvds= Received: from AS4P251CA0024.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:5d3::16) by DU2PR08MB10280.eurprd08.prod.outlook.com (2603:10a6:10:491::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.12; Tue, 3 Nov 2026 14:19:20 +0000 Received: from AM1PEPF000C1AD7.eurprd02.prod.outlook.com (2603:10a6:20b:5d3:cafe::8f) by AS4P251CA0024.outlook.office365.com (2603:10a6:20b:5d3::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.8 via Frontend Transport; Tue, 3 Nov 2026 14:19:20 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) 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.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by AM1PEPF000C1AD7.mail.protection.outlook.com (10.167.242.102) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Tue, 3 Nov 2026 14:19:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793715559; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=d0t/B6etdYG3qj1mkMNiIwqOaJneL4v0aqc0URMYaPo=; b=U5xJOvLxkwtgQU0+ooYjKBLOJH1EAKJn0LULt+eOqTOe3n4xKWzjewae0/mRbHCQ O1fjP7OAtbPc5YPtfektjeU5ryp25SYTGBvOP++O1zKHQaYTRfgYVN3eyVd2w20ld5h xRtvCkzvdCdSsfihxK8SRscQiaD2pbLeZtpkaW405+BRAi3d2zWXWLyXdap8POWoB+C yaDnTtM6gtAOtkvXg3bdwjB07fJD46ImquawLI2Ehagfg4dwuXmBeGliDm8LaM1cfLS vki8Db7vXCeyM8mVGuaRKnQzMplxg+YBl7mcFkqXjgQ/YLMyNKaA+m9VQyC3luO26Sh T3Rj9z9J3g== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793715559; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=d0t/B6etdYG3qj1mkMNiIwqOaJneL4v0aqc0URMYaPo=; b=XCzvpl9BCnQFvP21IronI6x4IMx6YiRLZlF4JHelLHHgTyjpPRbx5UhejAyQA6Tq KmsqxEE2GhcBHEEk4A2aQ/woAqULS0IiXRjZ2fI922v0wJQ/ZMEhgIzkH2coV/bu4S7 0lF3rRzKAJWOok+OqduZuoW5gyv+O5pRSU01/s0I= Message-ID: <010701a1a1c75c7b-86069160-327b-410d-a9e5-5cce343c76fa-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v7 24/35] kvm: fix coalesced MMIO flush racing with kvm_close() To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261103-vfio_v1-v7-24-4467fdccbbe6@virtuozzo.com> References: <20261103-vfio_v1-v7-0-4467fdccbbe6@virtuozzo.com> <20261103-vfio_v1-v7-24-4467fdccbbe6@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2026 14:19:19 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.11.03-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM1PEPF000C1AD7:EE_|DU2PR08MB10280:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: aa5c3568-3733-4f9e-6315-08df39b57392 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|48200799018|61400799027|9140799003|32142699015|261026140227099003|4143699003|56012099006|5023799004|261009223027099003|261028144727099003|5063699009|261022105027099003|261021121427099003|261026121527099003|10067099003|55112099003|18002099003|22082099003|16102099003|261102123227099003|4113699003|5113699003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Z0FiV2FqdzBZejlncjl6Z0dBSy80WXFLTUtMNGJMZHptRjZwQ1pxK1VSdVdG?= =?utf-8?B?SmNVQWJpQ3o4Z3BSSkhqaTRJYmRhc1diMFB3WFBFOG1FaFo5bUtoSXdlR1lv?= =?utf-8?B?NGRyYytFMmVtQmV0OGFnMXJ3TWxXMzBSTWhUVU1kMXdhdUNzRE5obGdXMWxX?= =?utf-8?B?QlBmSk8xdlZrQmIzc1d6TVB1YUUzdWU3ZEJMQXlRZ1hNSFlnMGlYMGxtdjA0?= =?utf-8?B?eUVYVkFsS0RJUTlVaVNlQ24zSWVIdjBCK2JCcXg1T2dnS2toZWxIbFo5dE5N?= =?utf-8?B?eTRONXh5b0ozME94UTNpVUY5M0tZMFZYdW0rZzZHdGdja3p2RTV5OG1XUGRK?= =?utf-8?B?UWhDS3A0c1MxN2NZVE5aOE5EajBjZkNXYTB0UllaYklRa3ArVHhBTjZjc2NZ?= =?utf-8?B?WldKU1VKaktscEsrNm40M3I0Q294c3ErNDlkSnNnbFk4bWFrU3U5TTRnZkNk?= =?utf-8?B?d0VGU1pyRE9tdXNpWEFRR3ZvTGZGa2tnSFdZWmdYK05kdHpFUmx3TWpkeE5N?= =?utf-8?B?T05CK0Y3Mm1XRm5na0ZRWURrQW9zSDJTZnZXUHpMcFliVTB5WW9qdXZmY1RH?= =?utf-8?B?TEgzTytGMFM3UWsxVDF0cTN5c0g1UGZVVkFlSXNjL0xxM3ZjUnBJNjE5R2Ur?= =?utf-8?B?ZlJoNW1PaThSVUpRN2xILzRkUTdpVVcxVy9nV0pwYnJGclpnTCt0N1ZkdGFq?= =?utf-8?B?ZFdpY2l0TElBRkFGMVdUN2t2MEpxT1NwYVdvYms2NVlhRWg1WklaSm1FTWl4?= =?utf-8?B?c0FWZ1VHMEpBZFFZU3FZZzNZRklOa05jVEVUNUVxREMvcU5CRUFnZm5FT3hD?= =?utf-8?B?TnFrQnBHbUZrYm0zMG5KWUd6ZDF5WEVYSnR5MzYzdmIrTnFLTjdXd1JHRzVU?= =?utf-8?B?dUxRcC9BREd5NkdXR3VGWG51ZWVOQ0VHQVJMVUt0R0l1dk5QdHU5NE1xN0py?= =?utf-8?B?WHQzajZyeXR1WFdJb1YxSkJadTR2T2h5eVhEanNZaFp0YjJKbmxjelU1WVdJ?= =?utf-8?B?Z2tyL3ljWHhlK3FKbG94RnNXdXArZmk1QjE0R3VKa21aK2ZUWVVYeGdmek5t?= =?utf-8?B?MVFHNXNJWTFrU3lpUXpvTjlrK1VBb1B5NS9pM3FNVEIrTmNrRGNKVVRSTHpm?= =?utf-8?B?QUt0VnJ3WFBKNlhyaThSWS9hWlhZRWpFS2ZJUGRNeWkyRVRzYlQ1bjFvREQ0?= =?utf-8?B?c1BXbFdzQWQzVWY4bllQUCszbkVJdHFVdE5uMThIeEdJb1dvcHd6MHIwZkRo?= =?utf-8?B?MXlhZVluTnNNUSt6NzVsNUZaVFdHNVQxT1ByT3A3STJ0L2N0Zz09?= X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(376014)(48200799018)(61400799027)(9140799003)(32142699015)(261026140227099003)(4143699003)(56012099006)(5023799004)(261009223027099003)(261028144727099003)(5063699009)(261022105027099003)(261021121427099003)(261026121527099003)(10067099003)(55112099003)(18002099003)(22082099003)(16102099003)(261102123227099003)(4113699003)(5113699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: DavlA3odCnCaW3YjtbOD3jT03NU5cy8wASLVTI/26Pk5srIzxoprHFqUCXnPB19ZOQ0dj9WigDLpPwmBVbOlnjaj43vyh0tcenJ6mylD0ddKwCZuSIum3R2o8GuqjbK2AkXDr/SztBpClv2nmwAH/Xvnbmk2OQbDB6IA1g9pK0jK3cQHqknorCL29eBrw6LnkIRb/CEDhg1lTrdv0hB/zVqnLJSi/zCXN3tAWtjhO8Qlq/V0rN5heD4N/JYjdRBTYoDpcu/m4O1muUoO9vbZWlDaJzKWpYK9Req47cLO8cQfP/mRzmuoEn7vCu26ExGn0owzvdPA91yyLXDJ+f+ZjAAOt+3slu6Ns59vOi+nyfuAOKO323y8bgZDDTnVD9du9gqENddx4dTR5kE1+iIgMou7hPelDmdu3FpWK9VXbfAbbEmfyllMtyBBMjHAFzzq X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2026 14:19:19.9992 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa5c3568-3733-4f9e-6315-08df39b57392 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM1PEPF000C1AD7.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10280 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] kvm: lockless coalesced_mmio_ring cleared with plain store racin= g with plain-load flush -- commit a37b91db7da68f58e8daa300e29ffcbb6cb539f1 Author: Andrey Drobyshev kvm: fix coalesced MMIO flush racing with kvm_close() This patch clears kvm_state->coalesced_mmio_ring and calls drain_call_rcu() at the start of kvm_close(), before the vCPUs are destroyed. The aim is to stop the RCU thread from flushing the coalesced MMIO ring after the vCPU kvm_run area has been unmapped. > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > --- a/accel/kvm/kvm-all.c > +++ b/accel/kvm/kvm-all.c [ ... ] > @@ -630,6 +630,14 @@ void kvm_close(void) > return; > } > =20 > + /* > + * Destroying vCPUs unmaps the coalesced MMIO ring, while the RCU th= read > + * may be flushing it from a memory region finalizer. Stop new flus= hes > + * and wait for the pending RCU callbacks first. > + */ > + kvm_state->coalesced_mmio_ring =3D NULL; > + drain_call_rcu(); > + [Severity: Medium] Can this plain store race with the lockless reader in kvm_flush_coalesced_mmio_buffer()? That function does: if (s->coalesced_mmio_ring) { struct kvm_coalesced_mmio_ring *ring =3D s->coalesced_mmio_ring; while (ring->first !=3D ring->last) { The check and the assignment to ring are two separate plain loads, with no qatomic_read() or READ_ONCE(). If the RCU thread runs flatview_destroy() -> memory_region_finalize() -> memory_region_transaction_begin() -> qemu_flush_coalesced_mmio_buffer() -> kvm_flush_coalesced_mmio_buffer() while the main thread stores NULL here, the store could land between the test and the reload. Then ring would be NULL and ring->first would dereference it. The only guard in the flush function is the plain bool coalesced_flush_in_progress, and the RCU thread does not take the BQL, so nothing orders the two sides. drain_call_rcu() runs only after the store. It covers a reader that already holds a non-NULL pointer, but it does not cover a reader that reloads NULL. The finding is speculative, since compilers normally merge the two loads, but it is a data race in C terms. The same plain-store pattern exists in do_kvm_destroy_vcpu(): if (s->coalesced_mmio_ring =3D=3D (void *)cpu->kvm_run + PAGE_SIZE) { s->coalesced_mmio_ring =3D NULL; } Would it be better to use qatomic_set() for the stores in kvm_close() and do_kvm_destroy_vcpu(), and a single qatomic_read() into a local variable in kvm_flush_coalesced_mmio_buffer()? Alternatively, could drain_call_rcu() be called first and the pointer cleared afterwards? > CPU_FOREACH(cpu) { > cpu_remove_sync(cpu); > close(cpu->kvm_fd); --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261103-vfio= _v1-v7-0-4467fdccbbe6@virtuozzo.com?part=3D24