linux-kernel - RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6E21E5352C11B742B20C142EB499E0481B74A8EE@TK5EX14MBXC126.redmond.corp.microsoft.com>
Date:	Sun, 4 Mar 2012 23:15:07 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"ohering@...e.com" <ohering@...e.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>
Subject: RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command
 to the host



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> Sent: Sunday, March 04, 2012 9:20 AM
> To: KY Srinivasan
> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; ohering@...e.com; hch@...radead.org; linux-
> scsi@...r.kernel.org; Haiyang Zhang
> Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> the host
> 
> On Fri, 2012-03-02 at 12:49 -0800, K. Y. Srinivasan wrote:
> > Windows hosts don't handle the ATA_16 command; don't pass it to the host.
> 
> What do you mean by this?  Most SCSI devices don't handle ATA_16 because
> it's only useful if the device is actually an ATA device behind a
> bridge.
> 
> As a general rule, you shouldn't filter in the driver commands you think
> the host won't want to see, you should let the host reply with an error
> code.  You should *only* filter commands that cause an actual bug in the
> host.  Is the latter the case for this command (if so that needs to be
> explained)?

As I explained in my email to Christoph, the Windows host returns error codes that
I cannot properly decode as being "unsupported opcode". Let me investigate a little more
and see if I can properly analyze the failure and return the correct error code up. If the error code
I get back from Windows is such that I cannot deduce the cause of the failure, then apart from filtering
the commands in the outgoing path, I am not sure what my options are.
 
> 
> > Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> 
> This signoff chain doesn't make sense, since you're sending me the patch
> and apparently you authored it.

Good point. Since I came to MSFT, this has been the practice here - 
all the patches were reviewed and "signed-off" by all the relevant developers
independent of the authorship and Greg seemed ok with it and has been ascribing
ownership based on the person sending the patch who is always the author of the
patch. How would you recommend we change this practice. 

Regards,

K. Y