From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a19bebd5eb-0e4bbf9e-7640-49ee-9287-bf896e982cd6-000000@eu-central-1.amazonses.com> Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazon11021113.outbound.protection.outlook.com [52.101.70.113]) by lore.virtuozzo.com (Postfix) with ESMTPS id ED75C80E7E for ; Mon, 2 Nov 2026 11:01:31 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JhSWjwK9BNXfY9tJxM0ACwuUiuQCVTRFi4s+eoDE7nzV8tOV9obm+K4fsSJGEzLnuISmLjhEQQ5VttNEqZ21/G7Q6m53Z4KjkxEJzgFot+yd+laM6g5xBcBaWpHQ9dkZBxyydGEcQHi4fXKo6Wln9V6DTujckrS11bm3R2J3Nvm3v9Slaq2Ej7yqazf0cA1PMH2olPsvu2Bf+eLXsH1uU63h9BNf0NlUX10TtpcB2RmTVBYF/uT0ZACAZ9ANDG8rtNEypM/Lbemt6BNhnyHYMaTap1mLjXZnN2fqibY1K3pN2KyiKlL6y+b4I/aeRKJfoXN61rThK7JWfMXqG899kg== 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=bL3xJC0Xku+bwX+9y1TM/UU3sgIQdLWq7UA2i06lSXM=; b=TsZK2xPvKMED+1vBvzLHG0if3DvupMzXQvm1xrYgTvSi3SpGK+6ECyX6SXlohfwnYIGUOtOfNE9eY134pj7jUl6IqQR0PVvqg403XRbVByJ5N5qwLc6EwRiKczYZFafQxEm/EknFl1bwkoq/QL2ayQIOXXpfHJv57vomvHcB2an/wuU/PhotM0Z1bHzGUIH0bGj8ZmNAavZ6HGirQdZGhKduxT7UsHBUZpaO50k4Uot2ENNc50tQFRccI782CogjV+1RC3klZgqIfSmHDuRYgxfUrwgUAFAdCNcKlU77hyVQjyvMPkzGtyb3cjzfnmWw4eHjq+7L80ji8+1V7SwHtw== 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=bL3xJC0Xku+bwX+9y1TM/UU3sgIQdLWq7UA2i06lSXM=; b=OjG3z0as+Vd9VpdOj/uPCP5k85eSP9A9SZBF4CZ2pChLP9cTzfUoP53Krwx70bEaDUmZxYjc2W6el7FG0QHWy7FXo495SYPelhRiq71AR/gR2t16d9ghrZejk76z6nJMMxhgUIkVHR+eMZLSFl6BzgLWXC4DNHgIfnQW2VdNXwE= Received: from LO4P123CA0195.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a4::20) by MIWPR08MB519056.eurprd08.prod.outlook.com (2603:10a6:290:eb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.12; Mon, 2 Nov 2026 11:01:27 +0000 Received: from MI3PEPF0000855E.eurprd05.prod.outlook.com (2603:10a6:600:1a4:cafe::57) by LO4P123CA0195.outlook.office365.com (2603:10a6:600:1a4::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.12 via Frontend Transport; Mon, 2 Nov 2026 11:01:27 +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 MI3PEPF0000855E.mail.protection.outlook.com (10.167.240.26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Mon, 2 Nov 2026 11:01:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793617286; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=dPhNp5zftAUSbwPhNkfz2knxWR4/5+og8nJJJWiY7Oo=; b=0V8lNwGF9Flnu4bNWcmWqWrOl5V2OU08dxN/0ZhylmXoMjktflKRnCKdc7hy0hKa 4PfsvjvyUqLAdodMNI62pQACu3QbMHPgk/EhpU8Txasfe9x6IpACu8DBrsOLAePYxUk eIj1ESTS/sTle0t0PDwjF010E6hB2LkhktXiXohl6yMQtyKdW2AqT1WLVQQFdUu47Zd 4teNZThgyaCeV2Rah6DL+cnd+A+zn7rsqfMkOUm9NEG/nq351WfH1VnlTSh+bYJDyzq JV/d1d4TAy73IR+MwSQcGAiHcUM8J/iga8rk9NpfugQkTzcj/4vYIp6W/QDgA452Tw+ ItGwvSGUVA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793617286; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=dPhNp5zftAUSbwPhNkfz2knxWR4/5+og8nJJJWiY7Oo=; b=Q9hl3ggdRXpSl6y7hZtAWJAzPJAXSrhDYFFe2WSmIPbPRzOhxxhrgzJ8PMe/tPP5 Biin/g1+yZm11ParqPVbwD7f2ZDcjtexBU5BrqQ96XQyRt54KKj3z8PXlDOOJ6hsZ0Z Fa9roeSR/jXUShQQvh/nVsOS5eDvEP8tNa+Pl/X0= Message-ID: <010701a19bebd5eb-0e4bbf9e-7640-49ee-9287-bf896e982cd6-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v6 22/34] kvm: tolerate ioctls after kvm_close() To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261102-vfio_v1-v6-22-9bc7cabc850d@virtuozzo.com> References: <20261102-vfio_v1-v6-0-9bc7cabc850d@virtuozzo.com> <20261102-vfio_v1-v6-22-9bc7cabc850d@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2026 11:01:26 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.11.02-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF0000855E:EE_|MIWPR08MB519056:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 41c41f30-f8dd-4403-7aad-08df38d0a456 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|9140799003|32142699015|61400799027|48200799018|3023799007|5113699003|4113699003|10067099003|55112099003|18002099003|16102099003|22082099003|56012099006|4143699003|5063699009|261021121427099003|261026121527099003|261022105027099003|261026140227099003|261009223027099003|261028144727099003; X-Microsoft-Antispam-Message-Info: 3HN8B/lKun1BqeCLSUWSo2904VClgDpXGWA3pb7eHLIY5sQ0RmdmyZwsAy2DTX7EFGlklstfaYK1mxDkudHQTI007fKUuuO8yBH2xjTFfdHL5dEO/mPC2uTdnhZfUHjwraZDOW3cKPrg8Py7TIEPES5IJuuhKpLBSvcsOD+IjcOk4DqQOvfOXtJExkNzCuNY8WuPAuzDYZHDm6IJpDV2YmgJJidaVnExYtBOfpLyZGAXWAHoqzhp/Wq8SI0Q7As9BRrAy4nNDM1Vgf5NBgr7JEqs0qLI+TPkEeZKjaSBQSFdDIpAFjtlQAXYyxS32mmlGEbOnhuKYqkWoTv+q8XmKD5GoxQll57kR3IBvXUc+uXC3ucn9A7rzWoi6fdsQbLg5tiHecab0BRUGdphzdiKpD+Y6SjiAm0/N/tn03jqt72FA9HgrIcYxYngCkeg0fHYSG0yYopugeZ6viUZAUiWvT0IMw3F4V0oObFNl8Hh3tipeyeW91aghXzS7Yz5J9WA2PMlpVeL8MiN4m4xkV8OwiapzKEGzG3hiODgRRrMjPjn1QSZ4dpbivT044sM3bl4h6jE9ZbglL1huzkEIUuzMGQAd29AxBW2dfbEhW/eiXDErl0itk5CJL0PQDqoCJ6W9zLGI0v17dmjkY0MmJlrnecSHXLlhudTq+/vHqnHNspi80XN/MCl5DxUCDJ4vgo47pyN7CLlFoHV9RN7tTjef1gvRxqlTsnMhZNQkYZDj+rAP5WuWQM/xTkld68Gyrv6Dfp+5BGaT3pFh8kCb6tf46ThCaHCE11fUGvTf+tV8H5F/2g7UhEDMSI+M+h6bdDkTEFm748Csddx/oeGg3odQZ1GDEAFE9GQvIwpZ2wBs58= 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)(376014)(9140799003)(32142699015)(61400799027)(48200799018)(3023799007)(5113699003)(4113699003)(10067099003)(55112099003)(18002099003)(16102099003)(22082099003)(56012099006)(4143699003)(5063699009)(261021121427099003)(261026121527099003)(261022105027099003)(261026140227099003)(261009223027099003)(261028144727099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: qFqsabWs1ubFm8jzbVcJtdxFngkosLP2c4lHHcArwss6vwljat+1fPUTZw9FgBCpoy9dTxo/irnb+MyDLhfu+UqH5kRbeEWPKRqTqEbyycmW6ATfDhJyUE+2j6fbEuDdDAkdo4XJa+PY8kW08sFvImBJaxdpJFSeBFmzRru61muVo0EGAArfZpHac9ea1dgI1vinCy+7wcAixG4M2N/FIuBnZ5WOcrfgcRTZisib5adOBvBQ28b3wOsIv7rUDJVQ79roRIwn1B7rz5sYe0SU+eex3EZp7kjKB9SQADiMXQltHYWC2jjb5TyGHp85y7NIhmSr1LXETaA8gKM0vKZYzpMHhs+iwDw3hBWJ2JFuWMr8qijr019uZZnhHwBTpepY9Wu4iHxr4rNWz1osND3tXy6Onzmi77wLS4h5PpvUrsyxVvjdFwEEL446x4i5lxXm X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2026 11:01:27.0680 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 41c41f30-f8dd-4403-7aad-08df38d0a456 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF0000855E.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: MIWPR08MB519056 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] kvm: ioctl wrappers return 0 after kvm_close(), faking fd 0 for = fd-returning ioctls - [Medium] kvm: closed-state ioctl guard returns 0 for fd-returning ioctls,= handing out fd 0 - [Low] kvm: stale fds left in kvm_parked_vcpus after kvm_close() now stay = reachable -- commit d8d6e98a861f3d1c2b3dafd0181c053060a2ea99 Author: Andrey Drobyshev kvm: tolerate ioctls after kvm_close() This patch keeps kvm_state allocated after kvm_close() instead of setting it to NULL. It makes kvm_ioctl(), kvm_vm_ioctl() and kvm_vcpu_ioctl() return 0 once the descriptors are closed. The goal is to stop a retired cpr-transfer source from crashing on late interrupts. > 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 [ ... ] > @@ -644,7 +644,6 @@ void kvm_close(void) > close(kvm_state->fd); > kvm_state->fd =3D -1; > } > - kvm_state =3D NULL; > } [Severity: Low] kvm_close() runs cpu_remove_sync() for each CPU, which reaches do_kvm_destroy_vcpu() and then kvm_park_vcpu(). That stores the vCPU fd number in kvm_state->kvm_parked_vcpus: vcpu->kvm_fd =3D cpu->kvm_fd; QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu, node); kvm_close() then runs close(cpu->kvm_fd). Only cpu->kvm_fd is set to -1, and the parked entry keeps the closed fd number. Before this patch kvm_state was NULL after kvm_close(), so this list could = not be reached. With kvm_state kept alive, can kvm_create_vcpu() get a stale fd from kvm_unpark_vcpu() on a vCPU hotplug after kvm_close()? kvm_create_vcpu() kvm_fd =3D kvm_unpark_vcpu(s, vcpu_id); kvm_init_vcpu() would then run mmap() and kvm_vcpu_ioctl() on that number. The kvm_vcpu_ioctl() guard does not catch this, because kvm_create_vcpu() has just assigned the stale value to cpu->kvm_fd. If the number has been reused, an unrelated descriptor would be used. If no parked entry matches, the new guard in kvm_vm_ioctl() returns 0 for KVM_CREATE_VCPU: kvm_fd =3D kvm_vm_ioctl(s, KVM_CREATE_VCPU, vcpu_id); if (kvm_fd < 0) { Here 0 is accepted as the vCPU fd, so cpu->kvm_fd becomes 0. The later patch in the series, "kvm: fix coalesced MMIO flush racing with kvm_close()", only clears coalesced_mmio_ring and calls drain_call_rcu(). It does not purge the parked list or guard kvm_unpark_vcpu(). [ ... ] > @@ -3389,6 +3393,11 @@ int kvm_vm_ioctl(KVMState *s, unsigned long type, = ...) > va_end(ap); > =20 > + /* kvm_close() has been called: there is no VM to talk to any more */ > + if (s->vmfd =3D=3D -1) { > + return 0; > + } > + [Severity: Medium] Can this blanket return 0 hand out fd 0 to callers of ioctls that return a new fd? Several of those callers only test for an error return, and the argument structure is not filled in. query_stats_cb() and query_stats_schemas_cb() only test for -1: stats_fd =3D kvm_vm_ioctl(s, KVM_GET_STATS_FD, NULL); if (stats_fd =3D=3D -1) { ... } query_stats(result, target, names, stats_fd, NULL, errp); close(stats_fd); After kvm_close(), a QMP query-stats or query-stats-schemas command gets stats_fd =3D=3D 0. The code then reads from fd 0 and calls close(0), which = closes stdin or whatever owns fd 0. kvm_create_guest_memfd() tests only fd < 0: fd =3D kvm_vm_ioctl(kvm_state, KVM_CREATE_GUEST_MEMFD, &guest_memfd); if (fd < 0) { A return of 0 is accepted there as a valid guest_memfd. kvm_create_device() returns the unfilled field as a success: ret =3D kvm_vm_ioctl(s, KVM_CREATE_DEVICE, &create_dev); if (ret) { return ret; } return test ? 0 : create_dev.fd; Here create_dev.fd is still -1. In hw/vfio/helpers.c, vfio_kvm_device_add_fd() has a similar problem: if (kvm_vm_ioctl(kvm_state, KVM_CREATE_DEVICE, &cd)) { ... } vfio_kvm_device_fd =3D cd.fd; vfio_kvm_device_close() resets vfio_kvm_device_fd to -1, so this path is taken again on a VFIO hot-add after kvm_close(). cd is initialised with only .type, so cd.fd is 0 and vfio_kvm_device_fd becomes 0. Later ioctl() and close() calls then act on stdin. It can be reached through iommufd_cdev_kvm_device_add() -> vfio_kvm_device_add_fd(). The commit message gives the reason for returning 0 only for interrupt injection, route commit and ioeventfd: Returning an error instead would still kill it: kvm_set_irq() aborts and kvm_irqchip_commit_routes() asserts on any failure, and the ioeventfd callers abort on a stale errno. That reasoning does not cover the ioctls that return a descriptor. Should those return a negative errno in the closed state, or should their callers check for the closed state? [ ... ] > @@ -3409,6 +3418,11 @@ int kvm_vcpu_ioctl(CPUState *cpu, unsigned long ty= pe, ...) > va_end(ap); > =20 > + /* kvm_close() has been called: the vCPU fds are gone */ > + if (cpu->kvm_fd =3D=3D -1) { > + return 0; > + } > + [Severity: Medium] Does this have the same problem for vCPU ioctls that return an fd? kvm_init_vcpu() sets: cpu->kvm_vcpu_stats_fd =3D kvm_vcpu_ioctl(cpu, KVM_GET_STATS_FD, NULL); If the vCPU fd is closed, this stores 0 as the stats fd. The follow-up patches in the series change only kvm_close(). They add no guard for any of these fd-returning callers. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261102-vfio= _v1-v6-0-9bc7cabc850d@virtuozzo.com?part=3D22