linux-kernel - RE: [PATCH 8/8] drivers: scsi: storvsc: Correctly handle TEST_UNIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Jul 2014 18:35:47 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"ohering@...e.com" <ohering@...e.com>,
	"jbottomley@...allels.com" <jbottomley@...allels.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"apw@...onical.com" <apw@...onical.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH 8/8] drivers: scsi: storvsc: Correctly handle
 TEST_UNIT_READY failure



> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@...radead.org]
> Sent: Wednesday, July 9, 2014 1:47 AM
> To: KY Srinivasan
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> ohering@...e.com; jbottomley@...allels.com; jasowang@...hat.com;
> apw@...onical.com; linux-scsi@...r.kernel.org; stable@...r.kernel.org
> Subject: Re: [PATCH 8/8] drivers: scsi: storvsc: Correctly handle
> TEST_UNIT_READY failure
> 
> On Tue, Jul 08, 2014 at 05:46:52PM -0700, K. Y. Srinivasan wrote:
> > --- a/drivers/scsi/storvsc_drv.c
> > +++ b/drivers/scsi/storvsc_drv.c
> > @@ -1023,6 +1023,13 @@ static void storvsc_handle_error(struct
> vmscsi_request *vm_srb,
> >  		case ATA_12:
> >  			set_host_byte(scmnd, DID_PASSTHROUGH);
> >  			break;
> > +		/*
> > +		 * On Some Windows hosts TEST_UNIT_READY command can
> return
> > +		 * SRB_STATUS_ERROR, let the upper level code deal with it
> > +		 * based on the sense information.
> > +		 */
> > +		case TEST_UNIT_READY:
> > +			break;
> 
> Don't we need to set an error in the command for the error handler to take
> action?  Or is this propagated elsewhere?

The host sets the appropriate scsi response and sense information that allows the upper-level scsi stack to appropriately recover. We are just making sure that we won't mark the target as failed which is what would happen in the absence of this patch since the host has set a very generic SRB error code that indicates failure.

Regards,

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/