[PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
James.Bottomley at HansenPartnership.com
Sun Mar 4 14:48:33 UTC 2012
On Sun, 2012-03-04 at 14:23 +0000, KY Srinivasan wrote:
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:hch at infradead.org]
> > Sent: Sunday, March 04, 2012 4:12 AM
> > To: KY Srinivasan
> > Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org;
> > devel at linuxdriverproject.org; virtualization at lists.osdl.org; ohering at suse.com;
> > jbottomley at parallels.com; hch at infradead.org; linux-scsi at vger.kernel.org;
> > Haiyang Zhang
> > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> > the host
> > On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> > > Windows hosts don't handle the ATA_16 command; don't pass it to the host.
> > Most devices don't handle it, and answer with and unsupported opcode
> > sense reason. If hyperv iis buggy enough to crap out on it please add
> > a comment explaining that.
> The host does not "crap out", it does return an error code but it is not "unsupported opcode".
> The sense reason that comes back is a generic error SRB_STATUS code. It is easier for me to filter the
> command on the outgoing side as opposed to dealing with a generic error code that is coming back from
> the host.
That's the wrong thing to do ... you need to unwrap the error code.
The reason being I presume it's not impossible for Windows to host a
device supporting ATA_16 and there are signs that this is going to be
necessary to prevent data corruption on some USB devices ... if you just
filter the command without checking if the host supports it, you're
going to end up perpetuating the corruption problem.
The general rule of thumb for avoiding this is to let the lower layers
handle as much as possible, and only begin behaviour alterations in the
upper layers if the lower layers have a provable and usually fatal
More information about the devel