From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazon11022081.outbound.protection.outlook.com [52.101.66.81]) by lore.virtuozzo.com (Postfix) with ESMTPS id 6391D8017D for ; Tue, 27 Oct 2026 11:42:06 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v4HBiM7lofrx2eYp5CE33ncMkO8vfzyGtvmLAo5l7mSjLfZ5m2bhsbaeoFIz4BMKs/rT3ifVUchVKWKGge5F4EB07nfJsnw25jrfURge6ADTckrhQNgeBNFbuTxSfNSU2NuS5LMc/TWJVNcrSdfzC2NuuXutUyWSolIjPqfitzk/ATFLt7Jr9jcuvEhWMEYash58JuujYXfiPU0w0cr/H+WFKiB3f7HSWX6jPBMdIoyPSYHShEs9YAEH2kvt7WzGcjYYZuH+ZCvKcWwEJy1nlU1FbTwcOZcXuKCiNpLxFKJgFD41i98Fiz+6DwCln5TSQcZiErtHMJxZoSsBNjWzOw== 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=U7xSN9M2KkmKJEnlE1oyMMdjglbpDHn38zCbcn0pRYw=; b=r/6pj8JP46AdbcqSmUqbqVLRm3TnOTA+UrBybn0StvMt1FJe4q7cojrpLA/Bmr9rlREWyTeENG6pD2bDsVRthDuS/39v/8Zq2qUgoyc6J8VS0shBKjMaJeHK8WzKsnfRStyyfXDYLTCEvVR9Os3P9jj0TM0txO+rwQ/QSd78n6JDx1EJFQdB9aU78A1Betfba+TI7F9nmostNoJn5tfryHyUpR1puHA1JIX0tEaS3vN5jWdjpfrppF8TjJp2jiuhnLlBi3O/yUT2twnTETfwty2aYMjhkJVQDDkpC9FrTMSISh2mVbzABQzd2NFRwb0PUMIxDNzKKzrJ0ic4r4IrMQ== 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=U7xSN9M2KkmKJEnlE1oyMMdjglbpDHn38zCbcn0pRYw=; b=JPabEc31Alv6G6xqubycbR3Cly7hoTOyapLn+eW9uv0gyIRBF08N6NXQMZa2T+N7Jt2lqYzXSjAi+O889ucR3277BQsMITjH1gL5YTcrQgkW7N90AFUi67tnHQ9Jk+YcQkiAYX6I8gafTGAiTbbQfC54Yl9FMiDlBTyE4IO4+4k= Received: from PAZP264CA0213.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:237::19) by MMZPR08MB180865.eurprd08.prod.outlook.com (2603:10a6:190:50::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 11:42:01 +0000 Received: from MI3PEPF00008484.eurprd02.prod.outlook.com (2603:10a6:102:237:cafe::6b) by PAZP264CA0213.outlook.office365.com (2603:10a6:102:237::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 11:42:01 +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 MI3PEPF00008484.mail.protection.outlook.com (10.167.240.171) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 11:42:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793101321; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=srIUec++plo8vlv/SZuWe2Ujl2AZLThPeogdYzZM8os=; b=oNz/otXTtK5rB2w7XpjZ6L7EhXzm8Z1U0SU+2PP7z88UKQHeMbGcv/j0tK/FQTki xMlDBHL+U2zLB+msxh0JN042lv0tBAOGvOv2Dx3WmZCw1BCPeZnW3AsezYeKvb7yUdQ 7QRSz3HM9K/tBLfUPL2cAa4hMmSIH9+l1npNBUk60cGv06nEUYMnlTWfHjPJB8AyfKP FTD+0yqI4SglY9AY4P7dhqdQjt6ei5wGUSSE6TRk9n/LHmz06LsGnJmiOtNiAEN1kQW uVNWB2aLalx3rxsJ7ABP6k6y/J1SUSX884jtEbOLVuaC5SrbRzsaHauVCueR3sOw8dT L7XUNLu4wA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793101321; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=srIUec++plo8vlv/SZuWe2Ujl2AZLThPeogdYzZM8os=; b=L/isQPemHRqGvG+gZqeinRy90eCLq1TqlvESpl9ZcPDurwmFqeSsHSAw49yu7fkO euIDBdGdY05REJFxOJ5qqcVSKKnEVdGt/w5Th7VVSduMy8n7Vw51acax1tULlQT7Lkn M8LASYgj3OIfN+FvlIdV/G+q1kp7773cVogjSprg= Message-ID: <010701a17d2ad2ac-44c7ccda-5042-4be2-af12-412689980ef4-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.1 2/2] linux-headers: drop VHOST_SET_NWORKERS To: andrey.zhadchenko@virtuozzo.com, Alexander Ivanov Cc: svt-core@virtuozzo.com, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261027113857.2928048-3-alexander.ivanov@virtuozzo.com> References: <20261027113857.2928048-1-alexander.ivanov@virtuozzo.com> <20261027113857.2928048-3-alexander.ivanov@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2026 11:42:00 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.27-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF00008484:EE_|MMZPR08MB180865:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6c4ebe8a-2bbb-4a42-7349-08df341f50c9 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|704160211799003|32142699015|61400799027|376014|48200799018|9140799003|261026140227099003|4143699003|56012099006|5063699009|261021121427099003|261022105027099003|261009221227099003|10067099003|261009223027099003|55112099003|22082099003|16102099003|18002099003|261026121527099003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: Zohy60cVusgoB86utsNJ34nbGxLVEZurZtA0mBxYvTsNTcYIVrkGd4VJPLqsIrIFOuULge5W1IhfhZbreXZzi5clZYtQet2uPGoormWIPIxgoWyVRNlP+vPVrEwTA5nObeC0EK4rE4c9tN/qYZe5zc9k6MkpNjjyILCs2AQhu9Cc1CaunL/LGU/+KD2Fpdjg20bvX1q4zUyc2o7LI20s33xh2LSj11FXroLV2IrRVUhrUseKUZXAG0Emp7T3I9HcVBSo80hdehJgof5WOacboAFSkbZK6GFwVu1vgosRx/iyL7S2TSBYh0HFjBwGajQBUOyGYbRtGq91eJ4GzlyiEX19W36ZSSG8Ll9o+sZZ3AY6FBIpNE8dKoHbRp7TMNg5lHia6b/P0BqBBooIzZqlPo00WeZXKjt1qDGxZnDVGt6jcGmSefXTyyhhrgUZfn/oNVAqtlUc0ocKVUygYsWrCmLLoS4/wVFCygvWiN4AjaSi0gU5LD1TelvR1aqcD2J1FxqYgNZFjehhey7/TeR8MmbyhsbrG82LXgGQqkXfcPOE0yjHmYRlOfRmVyBDwA2v8knPD4+2LRtkG1FaAUb3hYNV+LPuDbE5p+stp7hIe8a61fK81Ory6Vkirx2qqEkGJMK1e8M0Sjj4kPmdZp2K+VYOyeAFAPjzqpLWT1H3/B0yMLKQAMcNkk3smNJlgLky3K+yZXvKGTCD9GOdMBWYp8eo3xNCB+wt7oE/4KLxkVpTup+heGNV9Np/Nq9LN8EvtRE3+CtcTZUHurOezMirRdblylsLuO5rlxiaEmk4nDhO7QJY7otp6J9OXf4+g2WowkP4GtyXaWFtrX0Ww4t3N2vrYUJrMeghezjEqkeh46mB4aOyKsAvdGMMnhWTpoMlEH/b3wRe0lO1v0bd4nd3WV4Dr24Qdb52UffHnGdvDyw= 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)(704160211799003)(32142699015)(61400799027)(376014)(48200799018)(9140799003)(261026140227099003)(4143699003)(56012099006)(5063699009)(261021121427099003)(261022105027099003)(261009221227099003)(10067099003)(261009223027099003)(55112099003)(22082099003)(16102099003)(18002099003)(261026121527099003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: grFLDLXKjhmuGngANWJw7I+7Gju+40N7jwadiPPB8PVxNxNZOIY74ccmumM++lULprIvsQODeo8izRmQOC+HNOzVsyb8sVyskjmFf7HOrZ7ymHLnFic/cfksARhUXmQABQuVTW87JTdKJ/XGrXaP8F9n42S6rTYqRyIPaerjc75148lQnQ/Wb63zkiKAGwmwp47CTSMs2sEnb90BNE4S4eKx/0EV8NcUoJ+3bxMbfBYQMHC1gnmdDYUk6uZEVozctlpWMiaCxg0nubXvBDIJF0zR6kDxzVyxDOtqi9TPcRLDZ4wgCuZdfna+3WFv/6Ay/wDoJgJGk0DiwnIr2dDAQGHid/pKVPhVRFCGm3NxuuClicl7vPhApan7nmDbK3nYPYAKj59V5wvgHk6brlBOPhCtfFONWoxT2voHYN4X8lka9beXKXJLJeBQBzmBCGTg X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 11:42:01.3235 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4ebe8a-2bbb-4a42-7349-08df341f50c9 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008484.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMZPR08MB180865 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] vhost-blk: vhost_blk_start() leaks owner and workers on worker s= etup failure - [Medium] vhost-blk: ids[] stack overflow in vhost_blk_set_workers() when = num-queues/num-threads > 32 -- commit c5f15a317fc4cac3e42d0133296a66fbe1a1ca7d Author: Alexander Ivanov linux-headers: drop VHOST_SET_NWORKERS This commit removes the VHOST_SET_NWORKERS ioctl definition from linux-headers/linux/vhost.h, since vhost-blk no longer uses it and the kernel drops the ioctl. Link: https://virtuozzo.atlassian.net/browse/VSTOR-107537 > diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h > index baad06412d451..b6eb628d97389 100644 > --- a/linux-headers/linux/vhost.h > +++ b/linux-headers/linux/vhost.h > @@ -102,15 +102,6 @@ > #define VHOST_GET_VRING_WORKER _IOWR(VHOST_VIRTIO, 0x16, \ > struct vhost_vring_worker) > =20 > -/* Set number of vhost workers > - * Currently number of vhost workers can only be increased. > - * All workers are freed upon reset. > - * If the value is too big it is silently truncated to the maximum numbe= r of > - * supported vhost workers > - * Even if the error is returned it is possible that some workers were c= reated > - */ > -#define VHOST_SET_NWORKERS _IOW(VHOST_VIRTIO, 0x1F, int) > - > /* The following ioctls use eventfd file descriptors to signal and poll > * for events. */ [Severity: Medium] The two comments below are not about the lines removed by this header change. They concern hw/block/vhost-blk.c as modified by the preceding commit "vhost-blk: create kernel threads with the mainstream worker ioctls", which added vhost_blk_set_workers(). This patch does not touch that code, and no later commit in the series fixes either point. Can vhost_blk_start() leak the vhost owner and workers when worker setup fails? hw/block/vhost-blk.c:vhost_blk_start() { ... if (ioctl(s->vhostfd, VHOST_SET_OWNER, NULL)) { error_report("vhost-blk: unable to set owner"); return -ENOSYS; } if (nworkers > 1) { ret =3D vhost_blk_set_workers(s, nworkers); if (ret < 0) { return ret; } } ... } If VHOST_NEW_WORKER fails in vhost_blk_set_workers() (for example with -ENOMEM, a thread limit, or -ENOTTY), or a mid-loop VHOST_ATTACH_VRING_WORKER fails, the error is returned with the owner set and some workers already created or attached. Neither the helper nor vhost_blk_start() issues VHOST_RESET_OWNER or VHOST_FREE_WORKER. s->vhost_started is still false at that point, so vhost_blk_stop() returns early: hw/block/vhost-blk.c:vhost_blk_stop() { if (!s->vhost_started) { return; } ... } A retry of vhost_blk_start() before a reset would then fail, because VHOST_SET_OWNER on an already owned device returns an error that is reported as -ENOSYS. The resources are not permanently leaked. vhost_blk_reset() issues VHOST_RESET_OWNER on guest device reset and on the PAUSED and FINISH_MIGRATE handlers, and closing vhostfd in vhost_dev_cleanup() at unrealize frees everything. The serial-failure path (return -EINVAL after VHOST_SET_OWNER) and the set_guest_notifiers failure path have the same missing-reset pattern. That pattern predates the preceding commit, as did the old VHOST_SET_NWORKERS failure return. [Severity: Medium] Can vhost_blk_set_workers() overflow the ids[] array on the stack? hw/block/vhost-blk.c:vhost_blk_set_workers() { uint32_t ids[VHOST_BLK_MAX_QUEUES]; ... for (i =3D 1; i < nworkers; i++) { ... ids[i] =3D worker.worker_id; } ... } ids[] has VHOST_BLK_MAX_QUEUES (32) entries, and the loop writes ids[i] for every i below nworkers with no bound check. The only limit on nworkers is in vhost_blk_start(): nworkers =3D MIN(s->conf.num_threads, s->dev.nvqs); Neither input is capped at 32. In vhost_blk_device_realize() the VHOST_BLK_MAX_QUEUES cap is applied only in the VHOST_BLK_AUTO_NUM_QUEUES branch: if (conf->num_queues =3D=3D VHOST_BLK_AUTO_NUM_QUEUES) { conf->num_queues =3D MIN(virtio_pci_optimal_num_queues(0), VHOST_BLK_MAX_QUEUES); } An explicit num-queues above 32 is only checked for being non-zero and then flows into s->dev.nvqs. num-threads is a plain DEFINE_PROP_UINT16 in vhost_blk_properties with no upper bound. With an explicit num-queues=3DN (33 or more) and num-threads=3DM (33 or more), nworkers can exceed 32, and the writes to ids[i] go past the end of the array. The later attach loop reads ids[i % nworkers] and can also read out of bounds. This needs QEMU command line or QMP device_add access, so it is not reachable from the guest. Would it make sense to clamp nworkers, and reject num-queues above VHOST_BLK_MAX_QUEUES, in vhost_blk_device_realize() for explicit values as well? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026102711385= 7.2928048-1-alexander.ivanov@virtuozzo.com?part=3D2