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

target: Check number of unmap descriptors against our limit

2012-08-15T14:53:02Z

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-15T14:53:02Z

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-15T14:53:02Z

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-15T14:53:02Z

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-17T00:10:17Z

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 Cc: Cc: Signed-off-by: Nicholas Bellinger

target: Remove max_sectors device attribute for modern se_task less code

2012-05-09T22:08:47Z

This patch removes the original usage of dev_attr->max_sectors in favor of dev_attr->hw_max_sectors that is now being enforced by target core from within transport_generic_cmd_sequencer() for SCF_SCSI_DATA_SG_IO_CDB ops. After the recent se_task removal patches from hch, this value for IBLOCK backends being set via configfs by userspace from an saved max_sectors value that is turning out to be problematic, so it makes sense to go ahead and remove this now legacy attribute all-together. This patch also continues to make se_dev_set_default_attribs() do (sectors / block_size) alignment for what actually get used by target_core_mod to be safe here, following the same alignment currently used by fabric_max_sectors. Reported-by: Andy Grover Cc: Christoph Hellwig Cc: Roland Dreier Signed-off-by: Nicholas Bellinger

target: replace ->execute_task with ->execute_cmd

2012-05-06T22:11:14Z

Make CDB emulation work on commands instead of tasks again as a preparation of removing tasks completely. Signed-off-by: Christoph Hellwig Signed-off-by: Nicholas Bellinger

target: remove target_get_task_cdb

2012-05-06T22:02:59Z

Now that tasks are always the same size as the command there is no need to rewrite a CDB in common code. Notw that we keep the separately allocated CDB in the pscsi and stgt backends for now, to easy reintroducing any command splitting local to these backends if nessecary. Signed-off-by: Christoph Hellwig Signed-off-by: Nicholas Bellinger

target: stop splitting commands into multiple tasks

2012-04-15T00:40:31Z

From hch: The high-performance backends (iblock and rd) support tasks of unlimited size. With that there is no reason to keep a complex infrastructure for splitting up commands in place. Stop doing so and only submit a single task per data direction. Once this is in place we can slowly remove fields from the task that duplicate things in the command, or move other fields into the command. From nab: The benefit to IBLOCK performance by removing the additional fast-path allocation overhead + SGL mapping to se_task->task_sg[] is now greater than transparently supporting an received CDB I/O length that exceeds what is allowed by backend pSCSI LLD hardware max_sectors, that was originally supported for all backend export cases. This change may effect some users of pSCSI users on legacy hardware, but I think most folks are now using TYPE_DISK struct scsi_device export with IBLOCK. The only other place where this may can issues that cannot be resolved with IBLOCK TYPE_DISK is using TYPE_ROM, TYPE_TAPE or other pSCSI non TYPE_DISK export with an SCSI LLDs using a smaller max_sectors. Signed-off-by: Christoph Hellwig Signed-off-by: Nicholas Bellinger

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