From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023099.outbound.protection.outlook.com [52.101.72.99]) by lore.virtuozzo.com (Postfix) with ESMTPS id D86888017D for ; Tue, 27 Oct 2026 12:29:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eUULGe69o+4eriRBWpj0Z4+Bo2fQ7R0zVat7vopv9nuWll/ZikbihfriKHt54REUGrZvI/MTEBvgiKAppOp+tUlOjbaeXraCi6K57IvydxnGgIgxm/da0U34y69AGUqNMkf2Ud/YuqcIw6iZvODVBzJuJMcSqXfPKPkfnEFNeNUcEkm7wC6nUmp/s76Db3HxjLJDoj2zY5yEzEByxiGJIj9cDLIWccu3JsGzPRC+ELkmAvAPQYD9B5eLwSKxOJ6c/4XOJjBeVg4Erst0FY0Scxuz3AqyuN4jP+WSktGIDvuMbXhF95BlzcJvU1Qqm00W8Ovd3NBQ5N5OOydAaHB+sw== 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=/0Y7pR9WWBhPZCrvnjwD4FdMnFH9LMsyf166peEgM3E=; b=A/uSc7shi+Ic5qXJSNx5LbY7rxuyD9eY+qtBhU8q/9RpNRR980LEL7hK7pEClmKx7Msr328l+kRz6KGl/PoeHDP2RfzMdKzor0eRbnjFMNq575DuGAX2ovBInpBqwMovsL9+2uSXZFcOfVBuQiHvSexHze8QCcl/ntp7xEyJTYsuk3RjrBe8bRBM+Fccp/qHQ9zMfvoXdUrn5ewwSbki97Grt6Pv/9ivHrvU8b8oJ/St8HgVZxw7Vj4O4ReJw94e5PfBsmGkATqxtClwJVAftEtwQd+8dec+FsDQbNcPK1FPX0AeHknqwyFm8RACut1iF1HW+IcyEcoUcho4Dr8aFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/0Y7pR9WWBhPZCrvnjwD4FdMnFH9LMsyf166peEgM3E=; b=HMoiP3x6tQz3G1KJ8asZblN+IYuO8ZSKFPSlZzjL4g8MbcMz+RFqu3mu3iCaTxhaUZixBsrgshadXwcBwD1rsZiNKKBWohLjF6ZMerUvUtJ/CL3EgynmHRpauOdMWBfTZXo9neki51re4sSRt6u6DxUQrZp7SK2YDo3omb6nhFbjPeFF3xLoklTXzsb8QYdbDKZd0p8DS1wxlcp0yTaFtXEtAw03a9vAmAKM+bb3bZkY4i5RT4NiiJbGLB99qmZ90R92gIhjSvbIeHcfkenbJRakzRI2y/VwQ1BxGQoYFn6sF/QEPtEiLwNET5yUYXJuXUwxcYGdiC2uoYnxFINkPw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) by AS2PR08MB9152.eurprd08.prod.outlook.com (2603:10a6:20b:578::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 27 Oct 2026 12:29:41 +0000 Received: from VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a]) by VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a%6]) with mapi id 15.21.0546.017; Tue, 27 Oct 2026 12:29:41 +0000 Message-ID: Date: Tue, 27 Oct 2026 13:29:39 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hci-8.1 2/2] linux-headers: drop VHOST_SET_NWORKERS To: no-reply@sashiko.virtuozzo.com, andrey.zhadchenko@virtuozzo.com Cc: svt-core@virtuozzo.com, andrey.drobyshev@virtuozzo.com References: <20261027113857.2928048-1-alexander.ivanov@virtuozzo.com> <20261027113857.2928048-3-alexander.ivanov@virtuozzo.com> <010701a17d2ad2ac-44c7ccda-5042-4be2-af12-412689980ef4-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a17d2ad2ac-44c7ccda-5042-4be2-af12-412689980ef4-000000@eu-central-1.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: ZR0P278CA0036.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::23) To VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10743:EE_|AS2PR08MB9152:EE_ X-MS-Office365-Filtering-Correlation-Id: b9ee36f8-3560-454f-de0e-08df3425f94c X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr 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|23010399003|376014|1800799024|366016|18002099003|22082099003|5113699003|56012099006|4143699003|261026121527099003|261026140227099003|261021121427099003|10067099003|261009223027099003|261009221227099003|261022105027099003; X-Microsoft-Antispam-Message-Info: pZcHafiwcEU/Ly24YFeB6u/ptZqDuWkmxK8ceFEDeMoWsp/fHjG/GLm0KiEVxvzwefVNVGxXoVoE5XfbBJw/4zBhzPzpgZPjS+mIGWFNm5rh5Mymva8PT1faC1aqWzVaqFpvcBQiI0+9kHiseXFzdkjVjZzIL1pH12we9b1MzXZ4XEGjlV2NatanFjOGs5HUuOYMUulz11suoUptwJ8mAdHZHfHJkhJrGcUBfNFFuqYw3dINjOXGi36pYr1ZoIiVvX7Tuiud0sbFfDGgx6tnSztegjfiwenRKZ1zcub7nKXmR5c0HqVyJ2OPjXY/YUQI6oR/Pd+uEsrc4dMHHudvVRAfF4P+beD0D7bwhXp19mtQJepR8sfS1mA3T6KDmxhjjxlfB8Y209nNETCgchmV8yF6ewn54VypyImD86N3ar8UhvpQt+W4ND0apebCNIOcpYfs8PzTXxYx26NMd9RGuuUcCsdb6NRYM/n86eyttOP3Nqx/IvN7xRYz7ZBRTm0sIQV/3C5TyoFCp8oR9PqlPWF846N6SFueOjRDy/jsFmySG4WLkfUwELdA+nUx4f6v8R2u1Rlfa1WO9STzqLDz2oGNKKvMddTBfPmMC7Bo/q3j27mZvz4l9MEJe6vXDENCT5JZ1aaN5Wf2hBukB3E/e++2EVYAtSz/RwSd/9ANocI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR08MB10743.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(18002099003)(22082099003)(5113699003)(56012099006)(4143699003)(261026121527099003)(261026140227099003)(261021121427099003)(10067099003)(261009223027099003)(261009221227099003)(261022105027099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejRLODdvNWpkQ2dDSVU0UmFaV204V2NEVG51cDZ3cVlmSXpENkJjZ2M5cnhM?= =?utf-8?B?aXBTbFdWejM1NXdhR2FvTm52NmNqRzBkeGpjaHN6b3hKZTVSSUFlelVUaEJh?= =?utf-8?B?L01TcXpsdERuQmpBUzN5QlQvWTZGVFpRSVNVcTNJNStRNmRrT0RHOGp4NEZv?= =?utf-8?B?TzF5T2VsSnRKNkNUOVFSTGlsa3duTEhDT0w3b3VkemxqVWtEMU1FZ0NNWlVl?= =?utf-8?B?QnRxVU5JTzE0SFA4UEY3ZzRLdG5wRU1zTFFkZzUrd3JYUGJ1UG5JbGQ1M0dv?= =?utf-8?B?YkxhcnVaRDB3bEhqN29DVmNqbkU5aExkR3lWaFM2dnhhSU95VDNIUUQyNU52?= =?utf-8?B?RW9RQmM2UFB6ZzBJQ215VE9raFZtcHlVMk1VY2tjSWQyS2dyL1lKcmV4NXAz?= =?utf-8?B?dW1XTVJuWUgzOFlDT2djQmhoazRDNG9xd0JyK1JEQjQ0QXAya2EzenA3QW5B?= =?utf-8?B?UE9NUUpUSWVjSFhUa25GeUlQa1BGWHlMNTRhUEhmZ3hpTXJBb2UxVTQvNytu?= =?utf-8?B?K1c1UlplQ2FoTnRMeWZkWTFaN1BJV1VHcHlWWFFkcHplWVZrQ29FWTROZzBr?= =?utf-8?B?Unp1RnNjV3Yrc3BNTCtFQ2NJSWpGckRpc0tFaEFzQmpSQ21hOXF0Z21KL1dQ?= =?utf-8?B?cTFEN0pYaGpXc1VDOTBGT0d0WXpBYjdHd0N2RjkrWnkvUXhjUkZkU3JPQ0Yy?= =?utf-8?B?ZFd6ekhvbDQyZEZaU05wTGs3QVZ1RS9XVkRNTFREa1AvRDZvbThSL3RWak1X?= =?utf-8?B?VWtyTnAzdG81UFBTZWZHbTF3dWNCYytoemE0cXNFeFlPakdZSnpMTGlqcTZT?= =?utf-8?B?NWdVOE13bHRDNjRFY3FHSVJkeGpMa0pRSmhma1RlVXV4OW5TUlFlMGJOdlZJ?= =?utf-8?B?YWxBNms1ZWRDZExWRmUrbjhLaG12d3A3YWRNZjJyczRMdUNoZTRENFBRcEJp?= =?utf-8?B?UTc4UGdFSEVVKy9VOUN1WnRHRjczYkx6dzRJbUtyN2ovbGZHcEJNLzV5RHBP?= =?utf-8?B?VFpkczNyc1I1WVQwbTRkQnpBcGk4aVYvaDhGT2FGRkNPRjM1S2VHWFFXdGVV?= =?utf-8?B?RGV5T09TRGQ1ZmsxNXBYL0RNNVZHemZaRnhKbnhFRGFlMDZtUHFOczJwd01j?= =?utf-8?B?YnFNNWxEbHhoeWJJM2EwbDYxNWJuL0JPbFFHU0ladVRvby9NNm9KOE02UHZB?= =?utf-8?B?c05ETlI1SWFWalhJcnkvRjRlZ3pCV0NlOG1UdDBrV2NkaWd6NTZ5K2x1bzBi?= =?utf-8?B?SnNEbWdmUGRNbmxML2tVckpHS0dxa3h0UkhFZDkvM1o0Ujl2dE9DS0V5Q1o5?= =?utf-8?B?RXdQaHF6YUliTkxrcWNRL2pVNDJyZGM4Q1Z6VlZXS0pOcWk4cnJhNnJRRHR3?= =?utf-8?B?ZXBmWXFMYzdlTHJzSDB4ZFQzUlZ1a3V3Ry9YQmFHbmFpc1FwM2dDc3ZoK2Va?= =?utf-8?B?QUQ5c0Y1ZDlMcEhuRmdSY1lWOG1ScDFGdnMwVnFoUlNsTi9MVlNwcEoxOG5h?= =?utf-8?B?R0RrZWY3WGtpbmgrUjNGVUN4Yk53V2YyeWs5cDVnY1Y0bzVNemMzaHpETzds?= =?utf-8?B?YnJBSVh5SmdUZ0UvWjdMNExNenlMYldtTlN0SHMxMG5hUkU0WjR3SU1uTzJs?= =?utf-8?B?cWl2VkdFSkg3YWNNOWNwWHQxa0ZGUDJVcHNWWVEzODdpRnpFdWdTVmZvUDNi?= =?utf-8?B?TS9yRlJiWWFCSmRrSkFIVG9LbEh5a2tsZnBzU0EyVzhQcVVCc0RLMHhkNWQv?= =?utf-8?B?YnJiTHkvcUdid0xaSnByZjBnS2FBeExwMmkxNHFPS29vckJTaWo0amVRRGlP?= =?utf-8?B?VWFFN1lCN0M4ZzBlZGRiaXFkV250YVBTSU1NWnV2anRHSjEzdC9kekFBa0wv?= =?utf-8?B?M29Na1pBS21lUXlRUWRxdjF0WDVIdG02bnNvL1k4bDZzWGw4V1dMU1hOWWcx?= =?utf-8?B?WmllMmRNYXRsZXlDbnZudjF2dnZqUnY2VGoxSEZhSmdaNUhGTGxaNzhYemEx?= =?utf-8?B?VlphbG0rQjFWRTVyOHVSTUxhOE9PU2JyWlJJbVJSeHE5SkZzNU01YitUcVFC?= =?utf-8?B?RXQvTDM2TkE4aWpVQS9yVFFqQkdieDhubSt0QmJ6bjM3bnZDM09DM3IyaDRy?= =?utf-8?B?Rk11eTg2enRQdUFBcEwyU3FNZ0VFQ1IweGVUVlB3NlBvRXhGZ1FOT3d0Sndq?= =?utf-8?B?aGN5WkdaV3c5bDYxZUhISzF2VlMwWnZ1MmFjYWZlT2l2V2xKSExxWHRDMnVT?= =?utf-8?B?V212dDVJMjJVWkMvWm1PeEhTV3I0TnlwYVBuNmhJUWRHcFpyd1RTZXRnTkhy?= =?utf-8?B?VTh6cGlzMmErN281Wms5QlZVb0xpejVHVVlCRU50L2J0aG9PeXUvcXVRQlJY?= =?utf-8?Q?I1HCNKESnBZeO6bs=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9ee36f8-3560-454f-de0e-08df3425f94c X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10743.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 12:29:41.3109 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: p+J7M28Wl3IsjViMK7XAnSEUyFcMxsUNSryBndrUIrwONTv+bUqNARdomrgFDE5UrA6+pjb8bUoLI0eU2ny+hNz6qF9Y9NEUjNjmKaMlLp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9152 >> 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) >> >> -/* 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 number of >> - * supported vhost workers >> - * Even if the error is returned it is possible that some workers were created >> - */ >> -#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 = 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. Correct, but this is not a regression: the old VHOST_SET_NWORKERS failure path behaved the same way, VHOST_RESET_OWNER on device reset or closing vhostfd frees everything, and resetting the owner on every start error path is a separate pre-existing issue I'd fix in its own patch. > [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 = 1; i < nworkers; i++) { > ... > ids[i] = 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 = 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 == VHOST_BLK_AUTO_NUM_QUEUES) { > conf->num_queues = 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=N (33 or more) and num-threads=M (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? The clamp is already there: vhost_blk_set_workers() does nworkers = MIN(nworkers, VHOST_BLK_MAX_QUEUES) before the loop, so ids[] is only written and read below index 32. With more queues than that, the extra queues share the 32 workers round-robin.