kernel.git/drivers/target/target_core_cdb.c, branch linux-3.4.y

target: Fix trailing ASCII space usage in INQUIRY vendor+model

2013-09-08T04:58:16Z

commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream. This patch fixes spc_emulate_inquiry_std() to add trailing ASCII spaces for INQUIRY vendor + model fields following SPC-4 text: "ASCII data fields described as being left-aligned shall have any unused bytes at the end of the field (i.e., highest offset) and the unused bytes shall be filled with ASCII space characters (20h)." This addresses a problem with Falconstor NSS multipathing. Reported-by: Tomas Molota Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Check number of unmap descriptors against our limit

2012-08-15T15:10:32Z

commit 7409a6657aebf8be74c21d0eded80709b27275cb upstream. Fail UNMAP commands that have more than our reported limit on unmap descriptors. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

target: Fix possible integer underflow in UNMAP emulation

2012-08-15T15:10:32Z

commit b7fc7f3777582dea85156a821d78a522a0c083aa upstream. It's possible for an initiator to send us an UNMAP command with a descriptor that is less than 8 bytes; in that case it's really bad for us to set an unsigned int to that value, subtract 8 from it, and then use that as a limit for our loop (since the value will wrap around to a huge positive value). Fix this by making size be signed and only looping if size >= 16 (ie if we have at least a full descriptor available). Also remove offset as an obfuscated name for the constant 8. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

target: Fix reading of data length fields for UNMAP commands

2012-08-15T15:10:31Z

commit 1a5fa4576ec8a462313c7516b31d7453481ddbe8 upstream. The UNMAP DATA LENGTH and UNMAP BLOCK DESCRIPTOR DATA LENGTH fields are in the unmap descriptor (the payload transferred to our data out buffer), not in the CDB itself. Read them from the correct place in target_emulated_unmap. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

target: Add range checking to UNMAP emulation

2012-08-15T15:10:31Z

commit 2594e29865c291db162313187612cd9f14538f33 upstream. When processing an UNMAP command, we need to make sure that the number of blocks we're asked to UNMAP does not exceed our reported maximum number of blocks per UNMAP, and that the range of blocks we're unmapping doesn't go past the end of the device. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

target: Fix range calculation in WRITE SAME emulation when num blocks == 0

2012-07-29T15:04:18Z

commit 1765fe5edcb83f53fc67edeb559fcf4bc82c6460 upstream. When NUMBER OF LOGICAL BLOCKS is 0, WRITE SAME is supposed to write all the blocks from the specified LBA through the end of the device. However, dev->transport->get_blocks(dev) (perhaps confusingly) returns the last valid LBA rather than the number of blocks, so the correct number of blocks to write starting with lba is dev->transport->get_blocks(dev) - lba + 1 (nab: Backport roland's for-3.6 patch to for-3.5) Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Remove hack to make READ CAPACITY(10) lie if thin provisioning is enabled

2012-03-16T02:14:48Z

Remove the hack that has READ CAPACITY(10) return 0xFFFFFFFF as the number of sectors when thin provisioning is enabled. This is supposed to trigger the initiator to use READ CAPACITY(16) in this case so that it finds out about thin provisioning. But an initiator that cares about thin provisioning is going to ask anyway, and an initiator that doesn't know about READ CAPACITY(16) is going to get the wrong capacity. So just have READ CAPACITY(10) return the size it's supposed to. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

target: Untangle front-end and back-end meanings of max_sectors attribute

2012-02-25T22:37:49Z

se_dev_attrib.max_sectors currently has two independent meanings: - It is reported in the block limits VPD page as the maximum transfer length, ie the largest IO that the front-end (fabric) can handle. Also the target core doesn't enforce this maximum transfer length. - It is used to hold the size of the largest IO that the back-end can handle, so we know when to split SCSI commands into multiple tasks. Fix this by adding a new se_dev_attrib.fabric_max_sectors to hold the maximum transfer length, and checking incoming IOs against that limit. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

target: Don't set WBUS16 or SYNC bits in INQUIRY response

2012-02-25T22:37:49Z

SPC-4 says about the WBUS16 and SYNC bits: The meanings of these fields are specific to SPI-5 (see 6.4.3). For SCSI transport protocols other than the SCSI Parallel Interface, these fields are reserved. We don't have a SPI fabric module, so we should never set these bits. (The comment was misleading, since it only mentioned Sync but the actual code set WBUS16 too). Signed-off-by: Roland Dreier Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger

target: Set peripheral device type consistently in INQUIRY response

2012-02-25T22:37:49Z

Current code sets the peripheral device type to 0x3f == "not present unknown" for virtual LUN 0 for standard INQUIRY commands, but leaves it as 0 == "connected direct access block" for VPD INQUIRY commands. This is just because the check for LUN 0 only happens in some code paths. Make our peripheral device type consistent by moving the LUN 0 check into the common emulate_inquiry() code. Signed-off-by: Roland Dreier Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger