* [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC
@ 2026-04-06 1:53 Li Tian
2026-04-07 22:30 ` [EXTERNAL] " Long Li
2026-04-09 1:52 ` Martin K. Petersen
0 siblings, 2 replies; 4+ messages in thread
From: Li Tian @ 2026-04-06 1:53 UTC (permalink / raw)
To: linux-scsi
Cc: Li Tian, K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Long Li, James E.J. Bottomley, Martin K. Petersen, linux-hyperv,
linux-kernel
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=0x07 [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 <litian@redhat.com>
---
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 storvsc_cmd_request *cmd_request,
kfree(payload);
}
+/*
+ * 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] == 0x1c,
+ * and (for FC) MAINTENANCE_IN / PERSISTENT_RESERVE_IN passthrough.
+ */
+static bool storvsc_host_mishandles_cmd(u8 opcode, struct hv_device *device)
+{
+ 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 = &request->vstor_packet;
/*
- * 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] == 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 == 0x4) and off-line the device in that case.
*/
- if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
- (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
- (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
- (stor_pkt->vm_srb.cdb[0] == 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 = 0;
vstor_packet->vm_srb.srb_status = SRB_STATUS_SUCCESS;
}
--
2.53.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* RE: [EXTERNAL] [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC
2026-04-06 1:53 [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC Li Tian
@ 2026-04-07 22:30 ` Long Li
2026-04-08 18:06 ` Laurence Oberman
2026-04-09 1:52 ` Martin K. Petersen
1 sibling, 1 reply; 4+ messages in thread
From: Long Li @ 2026-04-07 22:30 UTC (permalink / raw)
To: Li Tian, linux-scsi@vger.kernel.org
Cc: KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
James E.J. Bottomley, Martin K. Petersen,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
> -----Original Message-----
> From: Li Tian <litian@redhat.com>
> Sent: Sunday, April 5, 2026 6:54 PM
> To: linux-scsi@vger.kernel.org
> Cc: Li Tian <litian@redhat.com>; KY Srinivasan <kys@microsoft.com>; Haiyang
> Zhang <haiyangz@microsoft.com>; Wei Liu <wei.liu@kernel.org>; Dexuan Cui
> <DECUI@microsoft.com>; Long Li <longli@microsoft.com>; James E.J. Bottomley
> <James.Bottomley@HansenPartnership.com>; Martin K. Petersen
> <martin.petersen@oracle.com>; linux-hyperv@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [EXTERNAL] [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN
> truncation for Hyper-V vFC
>
> 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=0x07 [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 <litian@redhat.com>
Reviewed-by: Long Li <longli@microsoft.com>
> ---
> 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
> storvsc_cmd_request *cmd_request,
> kfree(payload);
> }
>
> +/*
> + * 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]
> +== 0x1c,
> + * and (for FC) MAINTENANCE_IN / PERSISTENT_RESERVE_IN passthrough.
> + */
> +static bool storvsc_host_mishandles_cmd(u8 opcode, struct hv_device
> +*device) {
> + 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 = &request->vstor_packet;
>
> /*
> - * 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] == 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 == 0x4) and off-line the device in that case.
> */
>
> - if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
> - (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
> - (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
> - (stor_pkt->vm_srb.cdb[0] == 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 = 0;
> vstor_packet->vm_srb.srb_status = SRB_STATUS_SUCCESS;
> }
> --
> 2.53.0
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [EXTERNAL] [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC
2026-04-07 22:30 ` [EXTERNAL] " Long Li
@ 2026-04-08 18:06 ` Laurence Oberman
0 siblings, 0 replies; 4+ messages in thread
From: Laurence Oberman @ 2026-04-08 18:06 UTC (permalink / raw)
To: Long Li, Li Tian, linux-scsi@vger.kernel.org
Cc: KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
James E.J. Bottomley, Martin K. Petersen,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
On Tue, 2026-04-07 at 22:30 +0000, Long Li wrote:
>
>
> > -----Original Message-----
> > From: Li Tian <litian@redhat.com>
> > Sent: Sunday, April 5, 2026 6:54 PM
> > To: linux-scsi@vger.kernel.org
> > Cc: Li Tian <litian@redhat.com>; KY Srinivasan <kys@microsoft.com>;
> > Haiyang
> > Zhang <haiyangz@microsoft.com>; Wei Liu <wei.liu@kernel.org>;
> > Dexuan Cui
> > <DECUI@microsoft.com>; Long Li <longli@microsoft.com>; James E.J.
> > Bottomley
> > <James.Bottomley@HansenPartnership.com>; Martin K. Petersen
> > <martin.petersen@oracle.com>; linux-hyperv@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: [EXTERNAL] [PATCH] scsi: storvsc: Handle
> > PERSISTENT_RESERVE_IN
> > truncation for Hyper-V vFC
> >
> > 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=0x07 [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 <litian@redhat.com>
>
> Reviewed-by: Long Li <longli@microsoft.com>
>
>
> > ---
> > 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
> > storvsc_cmd_request *cmd_request,
> > kfree(payload);
> > }
> >
> > +/*
> > + * 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]
> > +== 0x1c,
> > + * and (for FC) MAINTENANCE_IN / PERSISTENT_RESERVE_IN
> > passthrough.
> > + */
> > +static bool storvsc_host_mishandles_cmd(u8 opcode, struct
> > hv_device
> > +*device) {
> > + 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 = &request->vstor_packet;
> >
> > /*
> > - * 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] ==
> > 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 == 0x4) and off-line the device in that
> > case.
> > */
> >
> > - if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
> > - (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
> > - (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
> > - (stor_pkt->vm_srb.cdb[0] == 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 = 0;
> > vstor_packet->vm_srb.srb_status =
> > SRB_STATUS_SUCCESS;
> > }
> > --
> > 2.53.0
>
Looks good, rewrite of how it was done before but will achieve the same
behavior we wanted for the new addition for PR.
Reviewed-by: Laurence Oberman <loberman@redhat.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC
2026-04-06 1:53 [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC Li Tian
2026-04-07 22:30 ` [EXTERNAL] " Long Li
@ 2026-04-09 1:52 ` Martin K. Petersen
1 sibling, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2026-04-09 1:52 UTC (permalink / raw)
To: Li Tian
Cc: linux-scsi, K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Long Li, James E.J. Bottomley, Martin K. Petersen, linux-hyperv,
linux-kernel
Li,
> 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.
Applied to 7.1/scsi-staging, thanks!
--
Martin K. Petersen
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-04-09 1:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-06 1:53 [PATCH] scsi: storvsc: Handle PERSISTENT_RESERVE_IN truncation for Hyper-V vFC Li Tian
2026-04-07 22:30 ` [EXTERNAL] " Long Li
2026-04-08 18:06 ` Laurence Oberman
2026-04-09 1:52 ` Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox