linux-stable.git/drivers/target/target_core_device.c, branch linux-3.5.y

target: Remove max_sectors device attribute for modern se_task less code

2012-05-09T22:08:47+00:00

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:14+00:00

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 obsolete DF_READ_ONLY usage

2012-04-14T23:04:58+00:00

This was used at one time as a hack by FILEIO backend registration to
allow a struct block_device that was claimed with blkdev_get (by a local
filesystem mount for example) to be exported as read-only (SCSI WP=1).

Since FILEIO backend registration will no longer attempt to obtain
exclusive access to an underlying struct block_device here, this flag is
now obsolete.

Reported-by: Roland Dreier 
Signed-off-by: Nicholas Bellinger

target: remove obvious warnings

2012-03-16T02:16:09+00:00

Get rid of a bunch of write-only variables.  In a number of cases I
suspect actual bugs to be present, so I left all of those for a second
look.

(nab: fix lio-core patch fuzz)

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

target: Use array_zalloc for device_list

2012-03-16T02:15:51+00:00

Turns an order-8 allocation into slab-sized ones, thereby preventing
allocation failures with memory fragmentation.

This likely saves memory as well, as the slab allocator can pack objects
more tightly than the buddy allocator.

(nab: Fix lio-core patch fuzz)

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

target: Use array_zalloc for tpg_lun_list

2012-03-16T02:15:38+00:00

Turns an order-10 allocation into slab-sized ones, thereby preventing
allocation failures with memory fragmentation.

This likely saves memory as well, as the slab allocator can pack objects
more tightly than the buddy allocator.

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

target: Fix off-by-seven in target_report_luns

2012-02-25T22:37:50+00:00

cdb_offset is always equal to offset - 8, so remove that one.  More
importantly, the existing code only worked correct if
se_cmd->data_length is a multiple of 8.  Pass in a length of, say, 9 and
we will happily overwrite 7 bytes of "unallocated" memory.

Now, afaics this bug is currently harmless, as allocations will
implicitly be padded to multiples of 8 bytes.  But depending on such a
fact wouldn't qualify as sound engineering practice.

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

target: prevent NULL pointer dereference in target_report_luns

2012-02-25T22:37:50+00:00

transport_kmap_data_sg can return NULL.  I never saw this trigger, but
returning -ENOMEM seems better than a crash.  Also removes a pointless
case while at it.

Signed-off-by: Joern Engel 
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger

target: fix use after free in target_report_luns

2012-02-25T22:37:50+00:00

Fix possible NULL pointer dereference in target_report_luns failure path.

Signed-off-by: Joern Engel 
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger

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

2012-02-25T22:37:49+00:00

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