[1/1] UBUNTU: SAUCE: hv_storvsc: Account for in-transit packets in the RESET path

From: "K. Y. Srinivasan" <kys@microsoft.com>

Properly account for I/O in transit before returning from the RESET call.
In the absense of this patch we could have a situation where the host may
respond to a command that was issued prior to the issuance of the RESET
command at some arbitrary time after responding to the RESET command.
Currently, the host does not do anything with the RESET command and so
it is ok to wait for the in-transit I/O to be accounted for. If the host
side sematics changes, we will have to revisit this.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>

BugLink: http://bugs.launchpad.net/bugs/978394
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
 drivers/scsi/storvsc_drv.c |    5 +++++
 1 file changed, 5 insertions(+)

On 11.04.2012 16:56, Andy Whitcroft wrote:
> From: "K. Y. Srinivasan" <kys@microsoft.com>
> 
> Properly account for I/O in transit before returning from the RESET call.
> In the absense of this patch we could have a situation where the host may
> respond to a command that was issued prior to the issuance of the RESET
> command at some arbitrary time after responding to the RESET command.
> Currently, the host does not do anything with the RESET command and so
> it is ok to wait for the in-transit I/O to be accounted for. If the host
> side sematics changes, we will have to revisit this.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/978394
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> ---
>  drivers/scsi/storvsc_drv.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5848a97..af3383f 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1223,7 +1223,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd)
>  	/*
>  	 * At this point, all outstanding requests in the adapter
>  	 * should have been flushed out and return to us
> +	 * There is a potential race here where the host may be in
> +	 * the process of responding when we return from here.
> +	 * Just wait for all in-transit packets to be accounted for
> +	 * before we return from here.
>  	 */
> +	storvsc_wait_to_drain(stor_device);
>  
>  	return SUCCESS;
>  }

Assuming this is a virtual scsi host driver used only in HyperV and coming from
t-h-e-m. So regression is limited that virtualization environment.

On 04/11/2012 08:56 AM, Andy Whitcroft wrote:
> From: "K. Y. Srinivasan" <kys@microsoft.com>
> 
> Properly account for I/O in transit before returning from the RESET call.
> In the absense of this patch we could have a situation where the host may
> respond to a command that was issued prior to the issuance of the RESET
> command at some arbitrary time after responding to the RESET command.
> Currently, the host does not do anything with the RESET command and so
> it is ok to wait for the in-transit I/O to be accounted for. If the host
> side sematics changes, we will have to revisit this.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/978394
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> ---
>  drivers/scsi/storvsc_drv.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5848a97..af3383f 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1223,7 +1223,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd)
>  	/*
>  	 * At this point, all outstanding requests in the adapter
>  	 * should have been flushed out and return to us
> +	 * There is a potential race here where the host may be in
> +	 * the process of responding when we return from here.
> +	 * Just wait for all in-transit packets to be accounted for
> +	 * before we return from here.
>  	 */
> +	storvsc_wait_to_drain(stor_device);
>  
>  	return SUCCESS;
>  }

Unless the SCSI layer is throttling requests after a reset command, then
I think this only makes the window smaller. AFAICT there is no locking
that would prevent a new I/O request from being submitted right after
the wait_to_drain event is signaled.

But ACK anyways.

rtg

On Wed, Apr 11, 2012 at 09:31:16AM -0600, Tim Gardner wrote:
> On 04/11/2012 08:56 AM, Andy Whitcroft wrote:
> > From: "K. Y. Srinivasan" <kys@microsoft.com>
> > 
> > Properly account for I/O in transit before returning from the RESET call.
> > In the absense of this patch we could have a situation where the host may
> > respond to a command that was issued prior to the issuance of the RESET
> > command at some arbitrary time after responding to the RESET command.
> > Currently, the host does not do anything with the RESET command and so
> > it is ok to wait for the in-transit I/O to be accounted for. If the host
> > side sematics changes, we will have to revisit this.
> > 
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > 
> > BugLink: http://bugs.launchpad.net/bugs/978394
> > Signed-off-by: Andy Whitcroft <apw@canonical.com>
> > ---
> >  drivers/scsi/storvsc_drv.c |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> > index 5848a97..af3383f 100644
> > --- a/drivers/scsi/storvsc_drv.c
> > +++ b/drivers/scsi/storvsc_drv.c
> > @@ -1223,7 +1223,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd)
> >  	/*
> >  	 * At this point, all outstanding requests in the adapter
> >  	 * should have been flushed out and return to us
> > +	 * There is a potential race here where the host may be in
> > +	 * the process of responding when we return from here.
> > +	 * Just wait for all in-transit packets to be accounted for
> > +	 * before we return from here.
> >  	 */
> > +	storvsc_wait_to_drain(stor_device);
> >  
> >  	return SUCCESS;
> >  }
> 
> Unless the SCSI layer is throttling requests after a reset command, then
> I think this only makes the window smaller. AFAICT there is no locking
> that would prevent a new I/O request from being submitted right after
> the wait_to_drain event is signaled.

I believe we are throttled for the whole of this callback.  We throttle,
call this reset handler, then unthrottle.  So I think we are safe
against new requests.

-apw