From nobody Sun Jun 14 20:03:56 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8065430F927 for ; Mon, 6 Apr 2026 01:54:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775440454; cv=none; b=mZRkMBweQXRA3IAJ2cOzjLSUWBU5zGjMhkg1WTpQjSdyvCRDsK9Me597ggTaKFulPs7n/HU0z1aQkG3xpKZGNxf5chisjes+VVNW/cNsI0p8w6GSG4FVN6FRJS/CBcg0U2R3mpP0lIzUcwv9+JJgwjdOd6Ibeuk4k72IvYVxMDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775440454; c=relaxed/simple; bh=2UTupawkM/Buasn6mvWU4ZaVvVjcElE7vIbTnBeKfFo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=djpPboqW1EXVXVvErYbhT+P4uRzLfUJAqMpUbM5RrN1fro/hEOs0FGPI6sGxjQRNirdPpxHYe5Uz6y08KVhQhQ3NNWNnVxXg2DGsmspb/8QEmx8g0b3hwwYzEui+6kD5EHTqBR0eXLbwpY12fmyCzybs6JKrAS4WkvL4o/iV7SI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KWm3dsAJ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KWm3dsAJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775440451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2t6NMj+k7e5t6BNImF47zecQxGvOdp4DtM9XCqytqzc=; b=KWm3dsAJGECN9Zik/PSrGT/myWZl461Gz4kHKoWHkJaiOTrvBtZUlc2UV3elz8TqYFoINg C3WftoxKcUwzY7kwpAD/tprchmNDmOPKzGq6Ur5Esq39QLUNxkyIWswy2efZqucFuNaeoE Qy6weVIt0HgZ8Xz7BXzjPptDXCAA3LE= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-76-Edb5DTryP7aHXD7Z2oDFWw-1; Sun, 05 Apr 2026 21:54:08 -0400 X-MC-Unique: Edb5DTryP7aHXD7Z2oDFWw-1 X-Mimecast-MFC-AGG-ID: Edb5DTryP7aHXD7Z2oDFWw_1775440446 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1D747180035C; Mon, 6 Apr 2026 01:54:06 +0000 (UTC) Received: from localhost.redhat.com (unknown [10.72.112.37]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BD81C300019F; Mon, 6 Apr 2026 01:54:00 +0000 (UTC) From: Li Tian To: linux-scsi@vger.kernel.org Cc: Li Tian , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , "James E.J. Bottomley" , "Martin K. Petersen" , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC Date: Mon, 6 Apr 2026 09:53:44 +0800 Message-ID: <20260406015344.12566-1-litian@redhat.com> 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 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" The storvsc driver has become stricter in handling SRB status codes returned by the Hyper-V host. When using Virtual Fibre Channel (vFC) passthrough, the host may return SRB_STATUS_DATA_OVERRUN for PERSISTENT_RESERVE_IN commands if the allocation length in the CDB does not match the host's expected response size. Currently, this status is treated as a fatal error, propagating Host_status=3D0x07 [DID_ERROR] to the SCSI mid-layer. This causes userspace storage utilities (such as sg_persist) to fail with transport errors, even when the host has actually returned the requested reservation data in the buffer. Refactor the existing command-specific workarounds into a new helper function, storvsc_host_mishandles_cmd(), and add PERSISTENT_RESERVE_IN to the list of commands where SRB status errors should be suppressed for vFC devices. This ensures that the SCSI mid-layer processes the returned data buffer instead of terminating the command. Signed-off-by: Li Tian --- drivers/scsi/storvsc_drv.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index ae1abab97835..6977ca8a0658 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1131,6 +1131,26 @@ static void storvsc_command_completion(struct storvs= c_cmd_request *cmd_request, kfree(payload); } =20 +/* + * The current SCSI handling on the host side does not correctly handle: + * INQUIRY with page code 0x80, MODE_SENSE / MODE_SENSE_10 with cmd[2] =3D= =3D 0x1c, + * and (for FC) MAINTENANCE_IN / PERSISTENT_RESERVE_IN passthrough. + */ +static bool storvsc_host_mishandles_cmd(u8 opcode, struct hv_device *devic= e) +{ + switch (opcode) { + case INQUIRY: + case MODE_SENSE: + case MODE_SENSE_10: + return true; + case MAINTENANCE_IN: + case PERSISTENT_RESERVE_IN: + return hv_dev_is_fc(device); + default: + return false; + } +} + static void storvsc_on_io_completion(struct storvsc_device *stor_device, struct vstor_packet *vstor_packet, struct storvsc_cmd_request *request) @@ -1141,22 +1161,12 @@ static void storvsc_on_io_completion(struct storvsc= _device *stor_device, stor_pkt =3D &request->vstor_packet; =20 /* - * The current SCSI handling on the host side does - * not correctly handle: - * INQUIRY command with page code parameter set to 0x80 - * MODE_SENSE and MODE_SENSE_10 command with cmd[2] =3D=3D 0x1c - * MAINTENANCE_IN is not supported by HyperV FC passthrough - * * Setup srb and scsi status so this won't be fatal. * We do this so we can distinguish truly fatal failues * (srb status =3D=3D 0x4) and off-line the device in that case. */ =20 - if ((stor_pkt->vm_srb.cdb[0] =3D=3D INQUIRY) || - (stor_pkt->vm_srb.cdb[0] =3D=3D MODE_SENSE) || - (stor_pkt->vm_srb.cdb[0] =3D=3D MODE_SENSE_10) || - (stor_pkt->vm_srb.cdb[0] =3D=3D MAINTENANCE_IN && - hv_dev_is_fc(device))) { + if (storvsc_host_mishandles_cmd(stor_pkt->vm_srb.cdb[0], device)) { vstor_packet->vm_srb.scsi_status =3D 0; vstor_packet->vm_srb.srb_status =3D SRB_STATUS_SUCCESS; } --=20 2.53.0