From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11020089.outbound.protection.outlook.com [52.101.69.89]) by lore.virtuozzo.com (Postfix) with ESMTPS id C3ECD8017D for ; Thu, 29 Oct 2026 09:28:00 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lhZAUaQC7hvg9IjngQ0PF591XDz5WlVDZlySecikAkO7S0z4sbQTBQIDz/CdVZ2dsoSS1oz0PTWgCek2q68C16jIRl4sesWsei1JEGxaR6WXpaejugQeoYseSzhzwmlaCeE9ZCKdX7djcy7p19DI3h7ETHcxWuQyQg/8Kbxv0nk60RVx73IafjGCIvMAUjP11VAYebnYkKbqjfgiiAQp8xCtxqbYRn5oUD9x5VamGyXicLXJLG2WVVH0SZmw3xJsiTdX0F5+51mJpHP4aeJbXOl9DefzmAGaMl/YfkRuFep5TJul8noUHjZLdoiErv07jAmqYy5zAf1r1/asVGNQCQ== 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=WWaVDQqC5btb+3a9bytF0B2xFDJO46be2W8rQsY2Mkk=; b=K/3xvDzmC+6DZF3BQXNreShFRZEc5w5A+paF5DErNaeYxnYPxQ6GBBH0No3870mvj1m5Uf29uMEYefTW1UEe5D70jcLkVVxToNX79KBilqXpWUPcX0uLeyGSE6arcGRuaCR5Jr26KEJYWYH8VrjOnrLBdQ3+k9X0Mxfb+J98p2y6TBf1y1Cv27uRo4lZLWD0aZN72/cuFSLf6SD3k9U8eyDqZepGodrdOlbVNP8KJM5WR4HcaCWK8dnqsQ5MtQsbDa0G+YUrpc7agukbTIQe1zuS6kcuOWSO6p06fwi6dRVVHud/QsLZTVq3BQ1nyazf7/G2V616Dw3cnq7+YniqNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) 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=WWaVDQqC5btb+3a9bytF0B2xFDJO46be2W8rQsY2Mkk=; b=jJsjflNgOd+WbnfUIuvAl4DcFDzZXM+soF3KYFhX0gs3wtWqo2B9Sfq3Dsz3No52B5GHtQV053ITvJUmLgnW7peCZ4ObdHyKshlHBzRTTnY4aDWe1lMFyf98zdEIVKPJwstPZG50Xne6etfGq+5bdcjFBV9JWvBpEGuGpOeA5IM= Received: from PR3P191CA0029.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::34) by PAWPR08MB9099.eurprd08.prod.outlook.com (2603:10a6:102:343::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Thu, 29 Oct 2026 09:27:57 +0000 Received: from MI3PEPF00008558.eurprd05.prod.outlook.com (2603:10a6:102:54:cafe::71) by PR3P191CA0029.outlook.office365.com (2603:10a6:102:54::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.8 via Frontend Transport; Thu, 29 Oct 2026 09:27:57 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) 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.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by MI3PEPF00008558.mail.protection.outlook.com (10.167.240.20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Thu, 29 Oct 2026 09:27:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793266076; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=gz5RjUuP907mDGMmXVgB1TAqhCT2V4f+Rar8XJIsCR4=; b=gkvQUDHM7T9BKac7qjajUNC96N+fK6BSYOXoTHKLr+gK5qpBSs/jLTpYKDsqvcle ZfoiD7RJsIIWp6DnQ/Fc+E5kgNn3Mldb3Cnctzv91C5csAmhAMCfbAN1DgjxzPompq5 v38JHS15Gwn0xVx3XiwfBwaFtsvCY99he6vnZcYxWruyR17KWOv+9tQSrIp7Ekmm65D Mh1ExuY0WMCSYBmBsISaytMAEXXfB/rghXdomiUd9PWiirzatG1vwyvQON2C/KZvRMS 8AATxeuqFvD0IbGVC9G71Yl+K3spUs/fnjrcraPw3QT0NOGGqCb3N+yMkPfgLn4Ylpg R02RCybeaA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793266076; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=gz5RjUuP907mDGMmXVgB1TAqhCT2V4f+Rar8XJIsCR4=; b=eJZuTg8w0qF9QOLou9QbOwL/HvgOJ1C48OjZbV4eYjgb5jVL1wOPivEiK9G32RiX qXfl5C7LJYKbnAl71Ln6/tub/Pp2uXzuF1UCl4/ylPqdzKNMFmiWUcMtMQ1IFfADUJr 1ZahneXOvBBCSjBWqd6dZUKoM+jBS+jDOurT1JS8= Message-ID: <010701a186fcc9a8-da101b26-0e65-456b-99df-3c7a0c7f620f-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.1 v4 4/5] vhost-blk: create kernel threads with the mainstream worker ioctls To: Alexander Ivanov , andrey.zhadchenko@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com, svt-core@virtuozzo.com In-Reply-To: <20261029092301.3286535-5-alexander.ivanov@virtuozzo.com> References: <20261029092301.3286535-1-alexander.ivanov@virtuozzo.com> <20261029092301.3286535-5-alexander.ivanov@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2026 09:27:56 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.29-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF00008558:EE_|PAWPR08MB9099:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 166b7f10-1c4a-43c8-2c72-08df359eea9d 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|376014|48200799018|61400799027|9140799003|32142699015|4143699003|56012099006|5063699009|261009221227099003|261009223027099003|261026140227099003|261026121527099003|261028144727099003|10067099003|261022105027099003|261022075727099003|55112099003|16102099003|22082099003|18002099003|4113699003|5113699003|13003099007; X-Microsoft-Antispam-Message-Info: KpTNuxbSct7YDGJtWhusR+1Ls/xoaPCpQtYR1a9kgoJe3ZE3JmUw/6Ip5oSnb1c2TB6rt7KSrle6kFBOEyhTCTJbjU9pc+EQEP5pWRd/QqrcTDtrvC+o+OaHFaenCSiBHRFGGiiseiUfFLVt+m6W20EJzObAz1jhlbfOJ/sMaUaWavYKXHwhCI9p4mk2x4WJ+ZbS8GDLp6SrngA361cW1CbFIXaKwDhJwIdD9lMemTYobV0h9RYig1/xdFDfIUsHsTaGBd2KMBRH3Iew8V+VAWHcV2/0+Fm116clzgEK1VQoi+av2FyYXBUF77U7yg/5ZqTysI1oKNv202Dw657shTQFBmf6dxF+y9+5FETiKpULfiF8IxiYTFQVVfJPukrZlBJuZ+b98zxShDOycW05Qjvyo7MWXftpBJUK05rPv3h08hFRUVK6gz1UTX+qAGihttTrriZCd3R/dXFzbYiy/BhBYPQC0PS+Tm2pXvewiVt+KJHUzqkCO7Hz+u/8jRATKZMYDfPJ9sOMGH8s+hAfMgcCQYOpGU/wg5esrexhEBtW0qAgVNYcJIHB3Jl7Wy4dBVbosd5bF0xl9XDLP96irPmPl5USnT/63/uuV+QKoMVLGmldGYda+lCkIoCJVwZmjFC20j3SgwoORb9XeuW+GvSfwoztiN8FiDP1W7UgcZKop3VOZol049d8Aqr6ixZNJ8BAuJ8NACQBZrvwwV9fyIuv/U37sWFVsFd+RkAkLhDmckh2bj32KtAzpO4XSoCQsKVSBh81DM5JuMsQpkKYkun0V8elm+zuVnOBHBbO/qe/LMsEInmtGobRp14wndJ+VwSd8is0T9PyT2Mz1yX7zmQmDumHiJOrWXiAfGIFu7SrQ2gWBpX3VDq3KDsWVgNuI6bEwgCf3Gmqozla/+BhPqupzYfVGVLkTMPIX+pI1HA= X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(376014)(48200799018)(61400799027)(9140799003)(32142699015)(4143699003)(56012099006)(5063699009)(261009221227099003)(261009223027099003)(261026140227099003)(261026121527099003)(261028144727099003)(10067099003)(261022105027099003)(261022075727099003)(55112099003)(16102099003)(22082099003)(18002099003)(4113699003)(5113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: OUmG6v/a2WGaAeqEWSLpNdFW2ODWGGgwFsYOvMrpwekdsC1I1rCJTLKsLWwKqH/gozXuHw5ZKkTxErV6/86vGaqHftQhx0A98OlHHZhG0tGyAJQmDAGxsC3L6q/L2RgdsFEjU61Nvy6UDpmYO1v8W0vi9yOSYN5JwADhXHGiV6fHNX0G0saxIOGi2wiVxSHXO9SITO5wfJAXV2W7kv8HFj7pfOOCY0yNtBLNr1l+UthOkB9EMMhQIP9rg192AfeTBsJPXxbcMt0dYAbVvyMlnx57A6NdclPRZmeCwkST30Bl+gnIgb/HmefxdLnITeph4w5HseoNRiyi4n8eTy+dT+LQqkLIhCNeRq8XAb39q1404FEd886iicDCEZ6EhdUhaJ6o1azEFC+sa4fYudceO244lXqRvgHd4Af4MzdFZINU98Lj7yCwWaLIebyLhKpd X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 09:27:56.6514 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 166b7f10-1c4a-43c8-2c72-08df359eea9d X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008558.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9099 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Low] vhost-blk: vhost_blk_set_workers() leaves vq on default thread on N= EW_WORKER failure - [Low] vhost-blk: num-threads=3D0 is silently accepted instead of rejected - [Low] vhost-blk: workers from vhost_blk_set_workers() not released on vho= st_blk_start() error paths -- commit 23b6bc10b68c2d486e285cf836111089db385f0f Author: Alexander Ivanov vhost-blk: create kernel threads with the mainstream worker ioctls This patch replaces the VHOST_SET_NWORKERS ioctl with VHOST_NEW_WORKER and = VHOST_ATTACH_VRING_WORKER. It spreads the virtqueues round-robin over num-t= hreads - 1 extra workers. It also switches the device to vhost_task mode wi= th VHOST_SET_FORK_FROM_OWNER before VHOST_SET_OWNER. Link: https://virtuozzo.atlassian.net/browse/VSTOR-107537 > diff --git a/hw/block/vhost-blk.c b/hw/block/vhost-blk.c > --- a/hw/block/vhost-blk.c > +++ b/hw/block/vhost-blk.c [ ... ] > +static void vhost_blk_set_workers(struct vhost_dev *hdev, int nworkers) > +{ > + uint32_t ids[VHOST_BLK_MAX_QUEUES]; > + int i, ret, err =3D 0, nfailed =3D 0; > + > + assert(nworkers <=3D ARRAY_SIZE(ids)); > + > + for (i =3D 1; i < hdev->nvqs; i++) { > + int w =3D i % nworkers; > + struct vhost_vring_worker vq_worker =3D { .index =3D i }; > + > + if (w =3D=3D 0) { > + continue; > + } > + > + if (i < nworkers) { > + struct vhost_worker_state worker =3D { }; > + > + ret =3D hdev->vhost_ops->vhost_new_worker(hdev, &worker); > + if (ret < 0) { > + warn_report("vhost-blk: unable to create kernel thread: = %s", > + strerror(-ret)); > + nworkers =3D i; > + continue; > + } [Severity: Low] When vhost_new_worker() fails for queue i, the code sets nworkers =3D 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 =3D 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? > + ids[w] =3D worker.worker_id; > + } > + > + vq_worker.worker_id =3D ids[w]; > + ret =3D hdev->vhost_ops->vhost_attach_vring_worker(hdev, &vq_wor= ker); > + if (ret < 0) { > + err =3D ret; > + nfailed++; > + } > + } [ ... ] > @@ -52,15 +99,24 @@ static int vhost_blk_start(VirtIODevice *vdev) > return 0; > } > =20 > + nworkers =3D MIN(s->conf.num_threads, hdev->nvqs); > + if (nworkers > 1) { [Severity: Low] With -device vhost-blk,num-threads=3D0, nworkers =3D MIN(0, nvqs) =3D 0, so every "nworkers > 1" branch is skipped and no warning is printed. The old code did this: nworkers =3D s->conf.num_threads; if (nworkers !=3D 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=3D0 on the single default thread intended? The commit message only says that num-threads=3D1 is unchanged. > + ret =3D hdev->vhost_ops->vhost_set_fork_from_owner(hdev, > + VHOST_FORK_OWNE= R_TASK); [ ... ] > + if (nworkers > 1) { > + vhost_blk_set_workers(hdev, nworkers); > } > =20 > 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 =3D 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? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026102909230= 1.3286535-1-alexander.ivanov@virtuozzo.com?part=3D4