linux-kernel - Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

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] [day] [month] [year] [list]

Message-Id: <c7a174fc-aec4-e8bb-b7ad-8c53a87046de@linux.vnet.ibm.com>
Date:   Wed, 21 Dec 2016 21:11:09 -0200
From:   Mauricio Faria de Oliveira <mauricfo@...ux.vnet.ibm.com>
To:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Hannes Reinecke <hare@...e.de>
Cc:     jejb@...ux.vnet.ibm.com, linux-scsi@...r.kernel.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        gpiccoli@...ux.vnet.ibm.com
Subject: Re: [PATCH] scsi: do not requeue requests unaligned with device
 sector size

On 12/21/2016 05:50 AM, Christoph Hellwig wrote:
 > How do you even get an unaligned residual count?  Except for SES
 > processor devices (which will only issue BLOCK_PC commands) this is
 > not allowed by SPC:
 >
 > "The residual count shall be reported in bytes if the peripheral device
 >  type in the destination target descriptor is 03h (i.e., processor 
device),
 >  and in destination device blocks for all other device type codes.

On 12/21/2016 06:09 AM, Hannes Reinecke wrote:
 > Which actually would be pretty much my objection, too.
 >
 > This would only be applicable for 512e drives, where we _might_ end up
 > with a residual smaller than the physical sector size.
 > But that should be handled by firmware; after all, that's what the 'e'
 > implies, right?

On 12/21/2016 12:01 PM, Martin K. Petersen wrote:
> I agree with Christoph and Hannes. Some of this falls into the gray area
> that's outside of the T10 spec (HBA programming interface guarantees)
> but it seems like a deficiency in the HBA to report a byte count that's
> not a multiple of the logical block size. A block can't be partially
> written. Either it made it or it didn't. Regardless of how the I/O is
> being broken up into frames at the transport level and at which offset
> the transfer was interrupted.

Christoph, Hannes, Martin,

Thank you all for your comments and pointers to the documentation/spec.
I'll carry it on with the HBA and storage folks.

cheers,

-- 
Mauricio Faria de Oliveira
IBM Linux Technology Center