From nobody Fri Jul 24 23:30:07 2026 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61050313E0D for ; Wed, 22 Jul 2026 06:36:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784702181; cv=none; b=cCVzeZYsjzQXhcGk9bhRSuXaeQGNgZbEvZpVmSk3jGFUR/vnIotaIEAd4YzmEEsZmi16340Awa+ilC7Segs5PanLkPS4Yi494E+s30jCS2sAfiYv8DycWvZP1m/Bj/TzNVRz6h7gxQMT87PdJfRil0OXLOZdvkzm219NAeE2IcQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784702181; c=relaxed/simple; bh=xsmEthjq16+kC+Vph+G1U9fU4ClDR58MsihFmYHvaU4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=g2CRdhmnkCYwtdVhiX6aB/lYZz3ex+3+MVZHbsh06w54d3lrdvdWNfwR4jdoHfRkDkixUb3BKJAgaEAmqRL92tKoEn1IHZI+Q/DqJ0niHjnYpP6RHtvvjRANZvxvpWbZ9bHQCQLpjJjvlw0etO0YPoEdUZz0g9TGfF/8QIxX+W8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=q5LGFO+l; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q5LGFO+l" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2cad4170e8eso173862365ad.3 for ; Tue, 21 Jul 2026 23:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784702180; x=1785306980; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=kO1PiIP2Hl5OInAMYdlLbjh+bJ0nA/ItDty/+1ZP4t0=; b=q5LGFO+lwPLq2HgYbN99hwUxFzn8j2ODDAZbalvLesFihhW75PTJXRjT56zrgljtty bQuWDiLX77yrZl835uTZzoo75wwOKXeluVaKOq7zpJL598wVjlEiZAqK+X0PR3oGKnLN K0l21ZUuGrnwa1iWg0qBpuXKa2VHyJSoeMn6YgPcTyuJhd/T/buZAoNtZ7NPvuHdjdNk VA3rNQnuvPqoM31mjdJ5GvHG648De1F9eVgIHN+GvEdiMPerO96iXzGEOj70/uEyyyyR TmtdSgeGmrQruMeapgjBRJYUVZ6uiKx6qf0mfPvKOb7ZalDmIyqHs+qkpUeg2mYujXUd UBAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784702180; x=1785306980; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=kO1PiIP2Hl5OInAMYdlLbjh+bJ0nA/ItDty/+1ZP4t0=; b=hnNtqnOIyYq3hFnx9Kvx8LlE7SgEzHCsenRPDDWo15jLT7XmWHkrDOSbjHQXs4ZGjp mYCDWlnHxsaI0VZ25u6vMO8CjjI2Jx34J2eWKBdSGDLwu7eA2A8p65JIardkj9ehORlF twyll/E5222qZ35EX2sqN7Do7/AXD4tcECy+EDeYFm5TFSGgSW4hejnUrd0BsqlKqOTk VCM45B3b5/dvNPx64jSRfnug3pXsL+wNkIJDF6mlOf+cQPSKBDpJDh45Ki0uKgodKJLX HKuyuspurfg4mlMVpPAOR87KOR0A75c+7plkR7Tgk5EnHrvToSiHNrumZh5od5RCDomF darA== X-Forwarded-Encrypted: i=1; AHgh+Rpx8p9HcF+5gVdKeetaatNoNCk1VoXw9NcZM8Nd/QyS4wfi+eLDaj49+yEetgjJFMEHZn2WPLqDLjVzodI=@vger.kernel.org X-Gm-Message-State: AOJu0YxWcU+VCBK/xxsI67dnHIfpCy89UDOVIxUSuvJ4m++1KlFLywhv 6vwR4uczTgn0y/OMPLgCP44abnxkNxbaRAYcoduCJa1e6QaCzLMDy3PY X-Gm-Gg: AR+sD100OW8md80jdDAW2iVKq6uks6WVxuTldOzhf6Ynn6HuoB12Scfm4SeEZZ48QoD jGGvdKfGlqxpaEwiC9JZxRU7f0+XgBKv0QWKxw91lWytELW5/A6HJRIJ6dhIQZD5X8abJDUxIjb K6iRqo7jzueYev0Y3AokAJ9Q9Q7WrlcPDbdaa1jjLY6uq1xfq9jsS8xrQVrCAs/Drfqmi7dywOi N5Mgbine8f9RyooMczOWZrbxKmCPtFxy3lzcWzTCx3xnVbPRLE68rM+GErNJ0G04NqnD9B1cXTB mDlHwlxiC8XF8djht9zktX1uw4tqYaIpkh7iqgVp3GAsxAp4jzUgKlyMmL+2uxYSFwLjb3RjJgL zLNkRiCf4Q6n9hIjJD/9pHh9iEbLEU22wVZ5gnSfwr1931+G3dS1dWVoA/60Jb2RR5XbIBLHu61 nR9g== X-Received: by 2002:a17:903:1a87:b0:2c8:25c8:85a6 with SMTP id d9443c01a7336-2cf3481b77fmr230776485ad.2.1784702179371; Tue, 21 Jul 2026 23:36:19 -0700 (PDT) Received: from gmail.com ([188.253.12.32]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf8f38a40fsm8908685ad.78.2026.07.21.23.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 23:36:19 -0700 (PDT) From: Jia Jia To: mst@redhat.com Cc: jasowangio@gmail.com, michael.christie@oracle.com, pbonzini@redhat.com, stefanha@redhat.com, eperezma@redhat.com, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, Jia Jia Subject: [PATCH] vhost-scsi: fix T10-PI lifecycle hard BUG after endpoint Date: Wed, 22 Jul 2026 14:36:09 +0800 Message-Id: <20260722063609.1546421-1-physicalmtea@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vhost_scsi_setup_vq_cmds() runs only from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) only when VIRTIO_SCSI_F_T10_PI is already set at that moment. Command pools are not rebuilt later. vhost_scsi_set_features() may still flip that bit after the endpoint is live: it updates acked_features and returns success without reallocating prot_sgl. That is a feature-versus-resource lifetime mismatch. The broken order is: VHOST_SET_FEATURES(0) VHOST_SCSI_SET_ENDPOINT setup_vq_cmds() sees no T10-PI -> prot_sgl stays NULL VHOST_SET_FEATURES(VIRTIO_SCSI_F_T10_PI) only acked_features changes; command resources stay as above submit a T10-PI WRITE with a 129-page protection payload The I/O path then follows the new feature bit while using the old command objects. vhost_scsi_mapal() (static, inlined into vhost_scsi_handle_vq() here) does: sg_alloc_table_chained(table, 129, first_chunk=3DNULL, nents_first_chunk=3Dinline_sg_cnt) With first_chunk NULL, __sg_alloc_table() sets curr_max_ents from nents_first_chunk and calls sg_pool_alloc(129). sg_pool_index() then hits: BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */ The kernel reported the following call trace and register state: Call Trace: ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 RIP: 0010:0x4 CR2: 0000000000000004 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081 The host worker dies and the machine stops accepting network service until reset. The missing object is prot_sgl after a post-endpoint T10-PI enable introduced by commit bf2d650391be ("vhost-scsi: Allocate T10 PI structs only when enabled"). I also checked the other feature bits handled around endpoint setup. Only T10-PI allocates this endpoint-time per-command resource and does not rebuild it on a later SET_FEATURES. LOG_ALL uses lazy tvc_log and already tears log storage down when cleared; HOTPLUG does not allocate prot_sgl. So the chosen fix is to refuse T10-PI enable/disable while an endpoint is active, rather than adding a second rebuild path in set_features(). Return -EBUSY if vs->vs_tpg is set and the T10-PI bit would change. Userspace must CLEAR_ENDPOINT, SET_FEATURES, then SET_ENDPOINT again so setup_vq_cmds() can allocate protection SGLs when needed. That matches the existing "build command resources at endpoint" model. Fixes: bf2d650391be ("vhost-scsi: Allocate T10 PI structs only when enabled= ") Signed-off-by: Jia Jia --- drivers/vhost/scsi.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 9a1253b9d8c5..000000000000 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -2219,6 +2219,7 @@ static int vhost_scsi_set_features(struct vhost_scsi = *vs, u64 features) { struct vhost_virtqueue *vq; bool is_log, was_log; + bool is_t10_pi, was_t10_pi; int i; =20 if (features & ~VHOST_SCSI_FEATURES) @@ -2234,6 +2235,13 @@ static int vhost_scsi_set_features(struct vhost_scsi= *vs, u64 features) if (!vs->dev.nvqs) goto out; =20 + is_t10_pi =3D features & (1ULL << VIRTIO_SCSI_F_T10_PI); + was_t10_pi =3D vhost_has_feature(&vs->vqs[0].vq, VIRTIO_SCSI_F_T10_PI); + if (vs->vs_tpg && is_t10_pi !=3D was_t10_pi) { + mutex_unlock(&vs->dev.mutex); + return -EBUSY; + } + is_log =3D features & (1 << VHOST_F_LOG_ALL); /* * All VQs should have same feature. --=20 2.43.0