RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2012-03-04 at 14:23 +0000, KY Srinivasan wrote:
> 
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:hch@infradead.org]
> > Sent: Sunday, March 04, 2012 4:12 AM
> > To: KY Srinivasan
> > Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> > jbottomley@parallels.com; hch@infradead.org; linux-scsi@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
failure.

James