From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazon11023118.outbound.protection.outlook.com [52.101.83.118]) by lore.virtuozzo.com (Postfix) with ESMTPS id CACFB80EC8 for ; Thu, 29 Oct 2026 09:57:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r1NdhSLLZe6i5WOCllE0/TCxywn5H/6OgRDzAv4Kv2BIHmP6Y74q5wo1z3BYlVjMwOk5UvTHHYgbcxE0IdQf/MrNzY0CUNC9wYV1waDAVks+lYZXnGHZRr0ZzaEUk8kKQbcmBiRyPwd7Itu/GG+XT4sUaWwyt766RlDFmpn354RnMnUWnD0E+a0i+I++G/gb30Cbxyh7B4jGlMB08o4+wxtzX4gUM7NlU7T3WyB4+7NQ2mklG4hkkYjOyeq6iWYWrfUSn/Skl7XfLch2wkgQydyKou+R9hV+/uUfvzDyv68HsX74LUq1+YYN35tp0ymdeJbMoNkZ/W7Th+bG8dlJ/g== 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=3yd4VtKWOZbY/1RzR3QHPUF8SgkQCqz4NqG7gvsvoR8=; b=cjn88EngKqECSaZZ16G84Ask5gZ2x5U4vjgP6nFiAzJ4fhE72jg0FFLGOuaSlDWCCFwx15oJCuid27FvZPXI80KUVxBcMhfl3rM7m0ZjH/hlEBPQZC0ZzW+tngL+hFT6Xm+dfcJKBeGRxd6bFJuLZpCQIjWaki3SzN0l/SoOxUZgbBAxV56ZR3H2oVfzNkBEhOZdLNYedsPlgVOUkJB9Tn88anzA0184UAAj40O4vlednSlkiosz8HT0lXAUU27CQIdX0I+NpK31v8VcgcQsuo6hVngWG3lrmqfvkGNGU8oQGw4lsErO4cUaaWUL5kgX4cPE8ptn3M/iZC5VelthKg== 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=3yd4VtKWOZbY/1RzR3QHPUF8SgkQCqz4NqG7gvsvoR8=; b=ZbXNOpsY0X1QBKN4pJEqo5K/rSGYObpsxiOwv1UtDCmGwfU/qFZfn8EPmuDqQvi/LfI+4mlLZmrnD6H665koZ6eqh3T3RtvqVFROUUC5ZChMIbSvzp45cD8i13cZWsapNuHUfTsodvgqptZFzxn9xt7S1H/jyMDx00BheX49aPXh+3c9ZVcRA3EA2FJsrKvqsP6v/eoP/GR2W5O5OMpnY5oLZLWWxJvuLsDdhcmPrRctMuAPnVa9ZQWXOlsdXIkHyd3+Z+8xKSPPIolSFpFcIZXhGZmxOuwVKbnDke64UIavB/5OiMJYzdDxqpE74HWznqQy16DNwpmvRF7SM+hRAA== 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 AS2PR08MB8745.eurprd08.prod.outlook.com (2603:10a6:20b:55d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 09:57:19 +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; Thu, 29 Oct 2026 09:57:19 +0000 Message-ID: <9df4f42c-7c89-4780-953f-ed5dd15a287d@virtuozzo.com> Date: Thu, 29 Oct 2026 10:57:17 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hci-8.1 v4 4/5] 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: <20261029092301.3286535-1-alexander.ivanov@virtuozzo.com> <20261029092301.3286535-5-alexander.ivanov@virtuozzo.com> <010701a186fcc9a8-da101b26-0e65-456b-99df-3c7a0c7f620f-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a186fcc9a8-da101b26-0e65-456b-99df-3c7a0c7f620f-000000@eu-central-1.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR0P281CA0212.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ac::11) To VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10743:EE_|AS2PR08MB8745:EE_ X-MS-Office365-Filtering-Correlation-Id: c40e36cc-c062-467a-d78c-08df35a304de 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|366016|1800799024|23010399003|376014|261028144727099003|261021121427099003|56012099006|4143699003|5023799004|261022105027099003|261022075727099003|261026121527099003|261026140227099003|10067099003|18002099003|22082099003|5113699003; X-Microsoft-Antispam-Message-Info: WxWwJbszJk3b393EiAeO0/KSmAfj8Khxj0gaLewyOkC/LAL8kDlUf19DZ4ge1QIFPpKpx2+5NzDRPVwThDiSurqu56GrIijxxvAkt/0f5RxXrPL/MMVKHUtrdWmd6JAWgQSRlUE30dw30rOyOnwPEwT33UiGbSyiOoGZjsi7K71SkxLfl4GEneZGRIE+96AFe2+kgFqCliHUxxne56J3aad37V6bwx4rUkjUJNzRVF7fcK8rS0+LxKRze1+gRPCPas7u7FyNuJeGybX/KQr8zY4JjOhG+MT+GzeyM6okpKqACVmfmFEC3i4VFnbixmJSCbnRaedV1s7QncYxpBPC22BXpsoFpRS6RO4NfKXa2Ib9Ibn3vDn2DDyrHLKHtdlXX/JBO/cUxubCTLFcVYbMjfpgxCxgvxouPs2O2arIHJFbjjcBG5DEi+uzN6kxO4U3qiNUsyiCrkRuYVi3tkxJPFKZrW0ITrTvUlAjthnJmBp2fXD2DY/v7HwDxaLF7o0froMW1tmxQM+KSnGz0WQyuHp26m9j7ghLQ8s8daHxT9lEhPCkHdyNlWHW5P8dlKMKY+SLiIw7RzOv48qNwWWGvleYMuaYy8+jIAv9ZuZNu3cz2eqiQQC0PpxerCL5fOykCZhGNPtB5g8DEFny0wDVDZnnewx5uUEnp0lIiDZkamY= 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)(366016)(1800799024)(23010399003)(376014)(261028144727099003)(261021121427099003)(56012099006)(4143699003)(5023799004)(261022105027099003)(261022075727099003)(261026121527099003)(261026140227099003)(10067099003)(18002099003)(22082099003)(5113699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1NFdm14dlloK0xMN3piR0hSSUVjREFQYUZmb1FRR1JNWTVvMTVSbk5oWHZH?= =?utf-8?B?VHNyOFRiRy9kUnV3MVBuWG1HREJFVnVGc2IzME56MjJDSzFIUmgrTGUxenJB?= =?utf-8?B?UXJRU1VmcjNNQTRPUmR5am05QjZHUnhYOGJWMTlBQzY2Njg2SDh3MVRLNUFz?= =?utf-8?B?MmlKV3ByNEpwc2I5M21aNlhhZWY2OUErRUpISjhyR3NsS0ExekZ0THRFNHVq?= =?utf-8?B?MEthSTlpbit2VFJSNEk1YUxzUHFLZFZjMHZhV3ZDWmdjR1BFL3F0V1I1ZkUw?= =?utf-8?B?NTJ1SzB3NUNUWjlXNGU2bmRqSjFzWEdxa2Vva1RwUThzNVVYb0RRYjllajgy?= =?utf-8?B?Wnk0SnBCK2VDOHFmdUxNQStGRkN4R1lST01QY1ZEYlNQdHRoSksrQ3JpWVdt?= =?utf-8?B?S29UN2NtcVVVbVM2UWloazd4TjJBdG1nTTM4Z1NoMlUzbzc4c1o5VmxFVlcz?= =?utf-8?B?dDRPS2VJTnlNWU5rUTF1Um1OZFh3T2ppRW13RmNmUXNrRGZkSnB4Q2hWaUtQ?= =?utf-8?B?MzE3NlVldHFHWit4Vzhmd2hYUS9CaXZEV3JxRUZmMVZSUW52KzlKL0xzNUVm?= =?utf-8?B?dDFja0ZJSVhJbHlZcTlCSTUzRk04dGdOMXlpNTJSbWNSYVM3WGpUVkFkazhN?= =?utf-8?B?VkxFTFl0MmdsTWtUWGtKempRNTE2ZmtVYnlWYjdHWmdWQ1N4RzczTm5DYkNF?= =?utf-8?B?cGZYdUdMdTJDWnQ5bnNNM3BVeHVLdmhnWGlnYzM5MzdidjBGN1dwNUc0R284?= =?utf-8?B?Y1dhNFBvM3VjZGtFMEhsV1cwOVUrdTFGdGo1OEFVa1VRK0VlLzllT3gydW91?= =?utf-8?B?WHJqTHJDM2tKNk4zb25YLzRybllqR1dVcHZTMFovdXBOV2NzbGw0enJad1hz?= =?utf-8?B?L3ljNm55MlNZcWZBNlhYa0VWc1M5dFhPS0NzOU81Ti8wbXhlT3U5dXp3TXJI?= =?utf-8?B?elpZUU5ZcjV3SnI2c1VnaE9lb2RsMFcrUDRrZjljQkt2TUUwS2wrUjFjQWhC?= =?utf-8?B?MEtmS2xraVNLcnFYbHEycGZodStZMk5WQ25EMGxkM0pSZElDc29FK2prZXpR?= =?utf-8?B?MXh6cmtGTURJaWxIbHJLUGlGZ1FLa3RRVDQyNnNlMVRxQXV1NnIxY0xBQ0FH?= =?utf-8?B?SEgvZFh0MWw2SC9BUlc2K2laVU0xWW54RmUwc1lLMUV3WHA3WGhxS1BSSlpN?= =?utf-8?B?QWcrSlNWRjNtLzFHMmN5SVdFa0VOTExVbVNEcWM2QitQaUxaRXE5b3orbDFx?= =?utf-8?B?aEVMTEJKQmRGK1NxNnd3US9NRWdjMGo4YmxZWDZ3UmFMbnpEYWkxRzZxbys5?= =?utf-8?B?eEpPdlVJdXZjS2FQRlgrdnpPbCtuSmxrbWZpcXhreGtheEc2RzR6THZlZHp6?= =?utf-8?B?eDcvTEhWdmp1eDFvNmQrZzJ5dHpTenZnbVIybStBQlhuYytPUStsM254WW1k?= =?utf-8?B?N3R1QzlTMkxDekdFbHQ5K25mODVxR3VaT2t1YlZCMTY2SHVJWEhVOFhtZVJm?= =?utf-8?B?R1E1TVdUaThLQ0Q3M1d1aENMOGcwOWUyNXN3c2cwQ3VpS2FRcStYUEplWkRK?= =?utf-8?B?T3hTazVnVjRRVENjWUpyOVZ5U1FkQTREVWhIc0tpRTBjeUlUSFZ0aThvQXh3?= =?utf-8?B?bmdyOWwrRmJkNEZITWpETlluMkJvYTVsN0ZKSGxoY0VBem1aMkg2bXRlSWdP?= =?utf-8?B?Qno2YTZvSzR2MjlQT3BvcWdwUGpzN1BwNEhkWFFwbm1xb0dyRTh0VE5lWUJG?= =?utf-8?B?QUlEa3IrTGVqcDJWVkJMNldtZG5ZYmlGNWZRNlFlV2FJais0V0EyeU5sY1hr?= =?utf-8?B?a1pCZ2haelVUZ2Q0dFd6NlhEUlBjL0hkYW5leFR2TDBRa0NPenk4aDNNKzNW?= =?utf-8?B?dUdvdk5pNG9BUDlMazFEd1VyMm5hdTdGQ2pIdVJKUW04bmVRdGVLVUd6ZzBG?= =?utf-8?B?NEF1TDN6V3ZVWi9oMS9nTUtsakNzY1pqKzdXbGt5QTN6Z1FCc25WVTN2VDAw?= =?utf-8?B?UFZ1QzhRbVRld3VZLzN3bThnQTdPNC9UTTA5UEUzR2VuSUN2T25qMm4yRGJx?= =?utf-8?B?dEt4b0l5S25qVlhRZzNYam1RRTRFc2twczRxRTBDVjVSUnlkSEMzcHlJejYr?= =?utf-8?B?aHVCNkZTSzdmMXVZNXRJUTdjNkZuVHIzY3V2MDh4OXRxVWFJdmI2Vm9pRFc3?= =?utf-8?B?WGNmc1BJSGRnaTBMMEhhTHppSTA3c0ZNYlZCeWVQUnN2ek1mSW1aY0UraEcx?= =?utf-8?B?cnlHWW5QL3RKUlNOdFYvMmJ3c0FsV040ZUdreTlmVURlUUdiNUJqdzY2R0E5?= =?utf-8?B?NXNic04rRHJDK3JEYXJzY3BoQm15NjlVZGg0V1VFZlpkanRCV0VmM3FZczhy?= =?utf-8?Q?97qsTH/TP0nBPmDM=3D?= X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: c40e36cc-c062-467a-d78c-08df35a304de X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10743.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 09:57:19.0570 (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: 9zWZD5B7su0R0fXZKoOoEGd/d6dgxexwL+IDz5XdpNCyOlewygUTPd4uI3THo0a52M31bcydzydtbirJ/mjG29Xqi7haM0KABJRi9rF/z58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8745 >> +static void vhost_blk_set_workers(struct vhost_dev *hdev, int nworkers) >> +{ >> + uint32_t ids[VHOST_BLK_MAX_QUEUES]; >> + int i, ret, err = 0, nfailed = 0; >> + >> + assert(nworkers <= ARRAY_SIZE(ids)); >> + >> + for (i = 1; i < hdev->nvqs; i++) { >> + int w = i % nworkers; >> + struct vhost_vring_worker vq_worker = { .index = i }; >> + >> + if (w == 0) { >> + continue; >> + } >> + >> + if (i < nworkers) { >> + struct vhost_worker_state worker = { }; >> + >> + ret = hdev->vhost_ops->vhost_new_worker(hdev, &worker); >> + if (ret < 0) { >> + warn_report("vhost-blk: unable to create kernel thread: %s", >> + strerror(-ret)); >> + nworkers = i; >> + continue; >> + } > [Severity: Low] > When vhost_new_worker() fails for queue i, the code sets nworkers = i and > does continue. Doesn't that skip the attach step for queue i itself? > > Queue i then stays on the default thread, even though workers 1..i-1 > already exist and could take it. Later queues are spread correctly, > because w = i % nworkers uses the reduced nworkers. > > The commit message says "if VHOST_NEW_WORKER fails partway, spread the > remaining virtqueues over the threads created so far". Should the failing > queue also be attached to one of the existing workers, for example by > recomputing w and falling through to the attach step? Queue i lands on thread 0, which is exactly where round-robin over the reduced nworkers puts it (i % i == 0); attaching it would be a no-op. >> @@ -52,15 +99,24 @@ static int vhost_blk_start(VirtIODevice *vdev) >> return 0; >> } >> >> + nworkers = MIN(s->conf.num_threads, hdev->nvqs); >> + if (nworkers > 1) { > [Severity: Low] > With -device vhost-blk,num-threads=0, nworkers = MIN(0, nvqs) = 0, so > every "nworkers > 1" branch is skipped and no warning is printed. > > The old code did this: > > nworkers = s->conf.num_threads; > if (nworkers != 1 && ioctl(s->vhostfd, VHOST_SET_NWORKERS, &nworkers)) { > error_report("vhost-blk: unable to set number of kernel threads"); > return -EINVAL; > } > > So 0 was passed to the kernel, and the device failed to start if the ioctl > rejected it. I could not check the kernel handler. > > The num-threads property is a plain DEFINE_PROP_UINT16 with default 1, and > I found no realize-time check that rejects 0. Is silently running > num-threads=0 on the single default thread intended? The commit message > only says that num-threads=1 is unchanged. This is intended and unchanged: the old VHOST_SET_NWORKERS handler accepted 0 without error (its worker-creation loop starts at 1, so all virtqueues stayed on the default thread), and MIN(num_threads, nvqs) with the nworkers > 1 checks keeps exactly that. >> + if (nworkers > 1) { >> + vhost_blk_set_workers(hdev, nworkers); >> } >> >> if (s->conf.serial) { > [Severity: Low] > Can the extra workers created by vhost_blk_set_workers() outlive a failed > start? > > Once vhost_blk_set_workers() has run, later failures in vhost_blk_start() > do not issue VHOST_RESET_OWNER or VHOST_FREE_WORKER. These are the > VHOST_BLK_SET_SERIAL failure, set_guest_notifiers, and the err_set, > err_disable and err_stop paths. > > The only place that does the teardown is vhost_blk_reset(): > > ret = ioctl(s->vhostfd, VHOST_RESET_OWNER, NULL); > > So after a failed start with num-threads > 1 and at least 2 virtqueues, the > owner and the extra worker threads seem to stay alive until a later reset > or until the vhost fd is closed. > > The missing owner reset on these error paths was there before this patch. > But this patch adds worker threads to what stays alive on them. I could not > verify how the vz kernel handles a retried VHOST_SET_OWNER. Should the > error paths release the workers? The extra workers live exactly as long as the owner, which a failed start already leaks, so adding VHOST_RESET_OWNER to the error paths is a separate fix.