From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11023123.outbound.protection.outlook.com [40.107.159.123]) by lore.virtuozzo.com (Postfix) with ESMTPS id 5AF7580CB2 for ; Tue, 27 Oct 2026 12:11:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kYL90SZb6hT0ZQl6l/h7CkkjZjxOitMhU4pQ9H6BSArEKpzi+if8+/h4LEOtl3pLnWNRhVjH7z6+btmYWuA19BtyDJqnRyjAaLMaR6Uzj7/q8B0jVYlr+Q0DtgUP8fUMfuPDl/UwFAwzD0O9HVZ6rZIlcjEAy2CdiApw55O9zyMsLe7GIBrQP1znRx+V+hCwmhQhhTwunBxFz68wqlIn2/BU71KDK5LlwEFfFSwb/Zq6CSksvXRYZ3HzwHHG9U3cF4XUu+8kiWijJpaP4zmz5EO7okjZNiV55nbru6sCAXMSjsJiw6nLh01zj7wKgtYvL9FLBJ5JcQPM3EEBHUXKFg== 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=K97qATiNKVhh1NmGh5c180Tv0bOs5g6CNsBrjNydm3A=; b=ZxXCriSYJ9kbcIO/zKx17Ze3PhscV8PgKITtFpffWV5JNCjohsQ+F2Cz9UfCJYRp9GGweKwD+o/nJcXMRjVdd5LC7QcPJbCgeB/lgJLCedK8iHAOOZIeNYvtq3PsV+sCodngGD8ltmlpBxkvc8iLolUV6uOrV/dfTgc8X1Q65JQh6b5Jpy+AO10rRiWRQe2CYiLObi28rPkd3hBKQaHIqGx5oItpbJpHkfM7HRQ4ocWH6fb3jRjSbOKqFBVrGBLlrb/PE6F+t4xIT9u7qn3NotqBWCYV8CYEYUAF1HQvUyQNck1DORNj71EwJ0zXfGMNTqNLcfqQuhnRZN/BK84ITA== 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=K97qATiNKVhh1NmGh5c180Tv0bOs5g6CNsBrjNydm3A=; b=boOxKkHx/vNwfcE56MQqLKJ2VzMYCbbjAh++FM3XlPIZyJQzGOTQlKO/8mpsmg57qHq79gWzjpLJ1D1tb7fk37N2K4ZpRNWlq7cRQvMrHkwqriPvuQWosN6qnTVuATh8V+GSn7g5YX0nsQcHW8lNRGoXZMSELpsBXE6i6LKhWvl+mFKVpEVMx+4bMUr28Pnccfc9k0gBKSpnqPNS7Tf9wuk64Ad2j4P++ZcPvHxUqMfUXvuYJz+R8lq7YHvz/olB3oMiETchM3Io8kjhGFB1r4FaAAueYFvjKVsqYANGdWQETLmLDnOVHN+pDRuGseB/OmagNF6Znwae2997pkEeDg== 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 VI1PR08MB5437.eurprd08.prod.outlook.com (2603:10a6:803:13d::7) 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 12:11:22 +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:11:21 +0000 Message-ID: <829bf354-5783-4b06-a43b-cabcfef97bf5@virtuozzo.com> Date: Tue, 27 Oct 2026 13:11:20 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hci-8.1 1/2] vhost-blk: create kernel threads with the mainstream worker ioctls To: no-reply@sashiko.virtuozzo.com, andrey.zhadchenko@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com, svt-core@virtuozzo.com References: <20261027113857.2928048-1-alexander.ivanov@virtuozzo.com> <20261027113857.2928048-2-alexander.ivanov@virtuozzo.com> <010701a17d2bfd69-07c611d4-bf3a-47f3-9970-bc829fc0ef42-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a17d2bfd69-07c611d4-bf3a-47f3-9970-bc829fc0ef42-000000@eu-central-1.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: ZR0P278CA0072.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:21::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_|VI1PR08MB5437:EE_ X-MS-Office365-Filtering-Correlation-Id: d06eb6ea-035c-49bb-4d88-08df342369dd X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|18092099006|22082099003|6133799003|18002099003|5113699003|261026140227099003|56012099006|4143699003|261021121427099003|10067099003|261022075727099003|261009223027099003|261009221227099003|261022105027099003|261026121527099003; X-Microsoft-Antispam-Message-Info: c6qm5Jrlz3U7V8NMoNZtXifswMwdtaEkIvCkwXoMET4PBmSlwjvvUnGK3s0IwZRcxq2k9OB1I8KiD4yGGdtDk5P2E0/XCMobWSyzWhY4hibwKuDi//UwDPdmBk8rwOI5kKhZLo2jxoGcZWVppf48KRtzVKU74g/vv93D0WfAXuxD+tYoV1d+zbUGUQ3sBYBlvP0N2DQBIOBb9wn8g835hcq2xAeaixNOQ3/FZiSn8dMMBZJ1XRY77/4IH76GEx637u/FF1hHNf5Q0IhwszoQPwZD2f0HyP8DBg/NynQAllLR4HLLSwlo/z1KRvCcKGb8HwpVuwutN2Sfhj/xSvWrPLVm1DMEMspf0P6xV8DBZ/LPqB37eEE4AkTsAjue5ZXcbyVnMOiMRLDu5zCHOA+eVUgU5iLf/JRCYNoWP8OMOteerZjYdagpbMqmIOdO1ANt+AuTojgFo1zZQRuavYykME0WR/CsTdOE+t6LgN19kB3GEFDLHXIjXhMfOkECXKbr39/GTxgpUIseYCs8jNZIgCU38bFORAJBqMvuUPjZucFRFMf75GX0D+PVQ53Gg29Ph0bYDHgvgRNsjqxom49mz1apLtcL0kPH8VovDg1mAjbuUai612jfCpUyFhuJtjpg9ZpRGiz8LQvHrHJA+zfsIREOgjGJ7+c8AcovHpgw6LA= 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)(376014)(23010399003)(366016)(1800799024)(18092099006)(22082099003)(6133799003)(18002099003)(5113699003)(261026140227099003)(56012099006)(4143699003)(261021121427099003)(10067099003)(261022075727099003)(261009223027099003)(261009221227099003)(261022105027099003)(261026121527099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RDJuT0hPK01ZRmlHWStWamRPWU9SdzdURWlpaDhhQm1sM1pOZ25ydjZDMVNR?= =?utf-8?B?TGVPN1laTTJsZDJLQjBjTk5xVE9uQkxsT3RwQnJhc055NitrSWlBTHZzYkJl?= =?utf-8?B?bWN6ZzZYb1hQaE5KUXZ4bUFPaVN3Y1dSU1lIcDMzeGtsS3Q3SXVycHhqLzFp?= =?utf-8?B?bWZodUdYSlZXeWZaZHprWURzUkswSVBjQW0wci9nS1ZQSEtYdVFUdmFhOVlQ?= =?utf-8?B?Y1EvZ2VSa1Jsd25qb2VVWnJUQmZTdE5PMUthY25hUFRXUUg4ZW5NVDBKZWtG?= =?utf-8?B?NzBoNEdBUGNuNlBwUnFkMWJwNTBCRStiQkVzeDhlZ3MvbHEvcHhtbEpIeis5?= =?utf-8?B?SHcrbzdRMnYzaGRmc0pkRkhuWHZUcDFJUk5kOGZ4Z0MzTHlBKzBGaGxJeWl1?= =?utf-8?B?Ujh3NWtHZjlZT3JoSXV6SzIvVVUyVi9CWENUNm9tZWRHZFVZU2NXTlg3R2hW?= =?utf-8?B?VXNvbVoyT3ZKazgrU2R5VnljeG8zeUF4d0hkZ1JBZHc3RHF4Q2xXZ0JjWWQ4?= =?utf-8?B?QjYrZjVDNUFmV2JTQ0RrUTFtbDFvMGJSSDZ3Q2F3dDFRMm11TEdwU1QrMjV5?= =?utf-8?B?YlhCRW5zbkRITS9MeTBjcEtGZnB4SGVYRGx0dTZVVldNYjk4MU51TXI3ZXBv?= =?utf-8?B?UFd2Y0pVdzBIU25xNjFwU1pGMHc4YzVvK09lNGVWS0RzZDFqZ3BYYU0wdGpu?= =?utf-8?B?RzFrUWZjdEx6QmhYbFVBYUdERTRsaHpLZCsxcGFsNkkrMjA0dWthZ25zVmFM?= =?utf-8?B?UmNJKzF6bUpBMXRWejZqdWZyeUNGYzE1djluc3lmbzBkY2xWaVhTa1RIcTc4?= =?utf-8?B?TDBHOHF5b0gyS0E4cDZXcHdzR2dUSHozM2hBaTVRbEhvdG5ZL1Z2ZWd0dEs4?= =?utf-8?B?U0lOeWpaa0RBdkRRTlFOR0NkTHB6T2NkSmZ3OTFMazdrVERMNnVCQTZnWUpp?= =?utf-8?B?eE15akliYUJIdmVXcDRxY0s1MmowM2NsWENaOGROeHpOYmFsbmg5bHR5TnM2?= =?utf-8?B?Z1dLRVlNaGpwaTFBbnh4a3NTZkJCMWw3RU92ODBIN2xMQ28vdVR4d2RMQVBL?= =?utf-8?B?TjN0ZUxTL1ZmREorRCtoTjdnekV4OWFoUEhXd1lHQWM3MVFmdi9xempJbDU2?= =?utf-8?B?Y2dVckhKTDJCQ1VHQzBtT3ZyRWZYSFNPNjU2MTNyUVBONmE1TkNDVFNqOFl2?= =?utf-8?B?cDE2alpMdVIvSDUzdmdMYlZqdDgrTmh4Y1pCeUFqcnNQenU1MXZKWkNJclNn?= =?utf-8?B?VWJkaTd4Qkhmb2pYZlpUYjFRU2k0UXlycFBVNU1JUGlYb21YZFJ4ZlJ3N29n?= =?utf-8?B?MEZzeUtUc2wzOTFnOG0xKzFlTHVnZFNPRzlJMjZsU3B6WkkydkllT0Y3TE5C?= =?utf-8?B?SWt2NkM4cUlTTnduMVRWNHB6Tkd6NENoRmlHSzVjNzhRWm5VTEs3WEQxbGdo?= =?utf-8?B?d2dkZjRRdEF3bHFkeVY0cVg0VlVOY2orajEvMk9yNjJtVXhmcGl5SXdJS0Q4?= =?utf-8?B?Nmp3dGFNbG9hUmx6bisxVHBkc2xnVlhFeWdsYk91VGVzTlk3RzE4NWswMkJp?= =?utf-8?B?UVRjekZWanRsbTVUK1dtYTVKL2J0cG5VVEtkaW9FNGdYOHBqaVk5OWc0NHZ6?= =?utf-8?B?aUJpQmVNWW0yblhaTld5MkF3VzJqS0NRUG41NmlRNzA5NHJtSlA2RnNlMEJD?= =?utf-8?B?MVpvTWQ2YlcwaGtGbUZRM2o4NG56STRkNG9ib1h3TmFmc1Zrb0ZRdnlBekt0?= =?utf-8?B?Y0t1bis0anB6UlhwL2x0UWttVDQ3WFZud3JKazlMUFRvdFY3S0JQclljZjcy?= =?utf-8?B?cTVDcDhsS0RMY3lTQkFST1VadGlYVFFHaXdkYnAyYkl2QVMvMnFwSno3bDdl?= =?utf-8?B?OG1RWjlJZjdvY28yKytpSVo0eU9pUFNHemdVWXBiN2RGaDRpdUpVckZRMGsz?= =?utf-8?B?MWhjT2NMc21LM0pCQllCTk5DdkNJMkNWVG5ReS9tUS9weG5UNXUzMDJsNCtS?= =?utf-8?B?L3lVZ1EwSlNYczBHakZiWU45aFJFSUZQdjc3cWZmVU02Um9WY2dEOHdsK2hp?= =?utf-8?B?cUNvQkxGcThVTUpKZ1hxZllwYlZ3SHBaNm53c05EaUVIYkFORGJ6Rm14VGdF?= =?utf-8?B?eTF1SEllMHhJT1RMVkFGYjdNelNhYkk1c0pwZlltdi9uelpjQWFjem9aTTdp?= =?utf-8?B?TVFjQXZVd25ISlJOT0E1N0VuR0xCUUhGK1NRR0xEanR5SHZySU9QblRKb2NV?= =?utf-8?B?bnEzblRob3BkSFEvZDJGSHU1bFlwM0hVb2RKZHViTjZjT21aOHFuL1J4K0Fj?= =?utf-8?B?V0JNUlJzd0w3RUtoelNJcWZIVGNyTThYeFhxd0VpRUFPdkNPRWx4WjVkcHlO?= =?utf-8?Q?0iYviLqEUD+cugyg=3D?= X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: d06eb6ea-035c-49bb-4d88-08df342369dd 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:11:21.6775 (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: uzdYbsbgbSHIspzcbTvCwIa0rwQZ9deTWqoqcf1I5oLlgOFzHXWBx+Z4FuDDAanUj/juAo/6Zppscg0t0x4hMC2v61RWpIG9dw7wlhPfUm8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5437 >> +static int vhost_blk_set_workers(VHostBlk *s, int nworkers) >> +{ >> + uint32_t ids[VHOST_BLK_MAX_QUEUES]; >> + struct vhost_worker_state worker; >> + struct vhost_vring_worker vq_worker; >> + int ret, i; >> + >> + for (i = 1; i < nworkers; i++) { >> + memset(&worker, 0, sizeof(worker)); >> + if (ioctl(s->vhostfd, VHOST_NEW_WORKER, &worker)) { >> + ret = -errno; >> + if (ret == -ENOTTY && i == 1) { >> + warn_report_once("vhost-blk: kernel does not support worker " >> + "ioctls, using a single kernel thread"); >> + return 0; >> + } >> + error_report("vhost-blk: unable to create kernel thread: %s", >> + strerror(-ret)); >> + return ret; >> + } >> + ids[i] = worker.worker_id; > [Severity: High] > Can this overflow ids[]? > > ids[] has VHOST_BLK_MAX_QUEUES (32) entries, but nworkers is bounded only > by nvqs. In vhost_blk_start(): > > nworkers = MIN(s->conf.num_threads, s->dev.nvqs); > > vhost_blk_device_realize() and vhost_blk_pci_realize() clamp num-queues to > VHOST_BLK_MAX_QUEUES only when it equals VHOST_BLK_AUTO_NUM_QUEUES: > > 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 value such as num-queues=64 is accepted and becomes > s->dev.nvqs. With num-threads=64, nworkers is 64. > > The loop above then writes ids[i] past the end of the stack array for > i >= 32. Fixed. > >> + } >> + >> + for (i = 0; i < s->dev.nvqs; i++) { >> + if (i % nworkers == 0) { >> + continue; >> + } >> + memset(&vq_worker, 0, sizeof(vq_worker)); >> + vq_worker.index = i; >> + vq_worker.worker_id = ids[i % nworkers]; > The same configuration also reads ids[i % nworkers] out of bounds when > i % nworkers >= 32. > > Should realize reject num-queues above VHOST_BLK_MAX_QUEUES, or should > ids[] be sized from nworkers or nvqs? Fixed. > > [ ... ] > >> static int vhost_blk_start(VirtIODevice *vdev) >> { > [ ... ] > >> + nworkers = MIN(s->conf.num_threads, s->dev.nvqs); >> + if (nworkers > 1) { > [Severity: Low] > Is it intended that num-threads=0 and values above nvqs are silently > clamped here? > > vhost_blk_device_realize() validates num-queues but has no equivalent > check for num-threads, and the property is an unconstrained uint16: > > DEFINE_PROP_UINT16("num-threads", VHostBlk, conf.num_threads, 1), > > With num-threads=0, nworkers becomes 0, the nworkers > 1 test is false, > and no worker ioctls are issued. Before this patch the old condition was > nworkers != 1, so a value of 0 reached VHOST_SET_NWORKERS. > > Would a realize-time check that rejects 0, or warns when num-threads > exceeds num-queues, make the behaviour explicit? The commit message only > says that num-threads=1 is unchanged. No behaviour change: the old VHOST_SET_NWORKERS handler already clamped n to nvqs and created no extra workers for n=0, and the patch does the same on the QEMU side. >> + /* >> + * VHOST_NEW_WORKER works only in vhost_task mode, and >> + * VHOST_RESET_OWNER brings the kthread default back. >> + */ >> + uint8_t fork_owner = VHOST_FORK_OWNER_TASK; >> + >> + if (ioctl(s->vhostfd, VHOST_SET_FORK_FROM_OWNER, &fork_owner)) { >> + ret = -errno; >> + if (ret != -ENOTTY) { >> + error_report("vhost-blk: unable to set vhost task mode: %s", >> + strerror(-ret)); >> + return ret; >> + } >> + warn_report_once("vhost-blk: kernel does not support vhost " >> + "tasks, using a single kernel thread"); >> + nworkers = 1; > [Severity: Medium] > Does this -ENOTTY fallback drop a working multi-thread configuration? > > linux-headers/linux/vhost.h documents VHOST_SET_FORK_FROM_OWNER as "Only > available when CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL=y". It also > documents VHOST_FORK_OWNER_TASK as the "(default value)". > > A kernel built without that option returns -ENOTTY here. According to the > header, such a kernel runs in task mode, which VHOST_NEW_WORKER and > VHOST_ATTACH_VRING_WORKER need. In that case nworkers = 1 discards a > usable setup. > > The commit message says "the kernel defaults to kthreads", which > contradicts the header. I could not check the kernel source for the target > kernel, so which one is correct is unverified. > > vhost_blk_set_workers() already handles -ENOTTY from VHOST_NEW_WORKER when > i == 1, with its own warning and single-thread fallback. Is the earlier > -ENOTTY fallback needed, given that? Our kernel, unlike the mainline header, defaults to kthreads, so without CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL VHOST_NEW_WORKER fails with -EFAULT, which the vhost_blk_set_workers() fallback does not catch, so the early -ENOTTY fallback is needed (commit message reworded to say "unlike mainline").