linux-toradex.git/drivers/target, branch v3.5.7

target: simplify code around transport_get_sense_data

2012-10-02T17:38:58+00:00

commit 27a2709912ac19c755d34c79fe11994b0bf8082b upstream.

The error conditions in transport_get_sense_data are superfluous
and complicate the code unnecessarily:

* SCF_TRANSPORT_TASK_SENSE is checked in the caller;

* it's simply part of the invariants of dev->transport->get_sense_buffer
  that it must be there if transport_complete ever returns 1, and that
  it must not return NULL.  Besides, the entire callback will disappear
  with the next patch.

* similarly in the caller we can expect that sense data is only sent
  for non-zero cmd->scsi_status.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: Fix ->data_length re-assignment bug with SCSI overflow

2012-10-02T17:38:58+00:00

commit 4c054ba63ad47ef244cfcfa1cea38134620a5bae upstream.

This patch fixes a long-standing bug with SCSI overflow handling
where se_cmd->data_length was incorrectly being re-assigned to
the larger CDB extracted allocation length, resulting in a number
of fabric level errors that would end up causing a session reset
in most cases.  So instead now:

 - Only re-assign se_cmd->data_length durining UNDERFLOW (to use the
   smaller value)
 - Use existing se_cmd->data_length for OVERFLOW (to use the smaller
   value)

This fix has been tested with the following CDB to generate an
SCSI overflow:

  sg_raw -r512 /dev/sdc 28 0 0 0 0 0 0 0 9 0

Tested using iscsi-target, tcm_qla2xxx, loopback and tcm_vhost fabric
ports.  Here is a bit more detail on each case:

 - iscsi-target: Bug with open-iscsi with overflow, sg_raw returns
                 -3584 bytes of data.
 - tcm_qla2xxx: Working as expected, returnins 512 bytes of data
 - loopback: sg_raw returns CHECK_CONDITION, from overflow rejection
             in transport_generic_map_mem_to_cmd()
 - tcm_vhost: Same as loopback

Reported-by: Roland Dreier 
Cc: Roland Dreier 
Cc: Christoph Hellwig 
Cc: Boaz Harrosh 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: fix NULL pointer dereference bug alloc_page() fails to get memory

2012-09-14T16:59:24+00:00

commit d0e27c88d795fb9647153063ec48051fd84e1731 upstream.

I am hitting this bug when the target is low in memory that fails the
alloc_page() for the newly submitted command. This is a sort of off-by-one
bug causing NULL pointer dereference in __free_page() since 'i' here is
really the counter of total pages that have been successfully allocated here.

Signed-off-by: Yi Zou 
Cc: Andy Grover 
Cc: Nicholas Bellinger 
Cc: Open-FCoE.org 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: Check number of unmap descriptors against our limit

2012-08-15T14:53:02+00:00

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

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

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

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

iscsi-target: Drop bogus struct file usage for iSCSI/SCTP

2012-08-09T15:22:35+00:00

commit bf6932f44a7b3fa7e2246a8b18a44670e5eab6c2 upstream.

From Al Viro:

	BTW, speaking of struct file treatment related to sockets -
        there's this piece of code in iscsi:
        /*
         * The SCTP stack needs struct socket->file.
         */
        if ((np->np_network_transport == ISCSI_SCTP_TCP) ||
            (np->np_network_transport == ISCSI_SCTP_UDP)) {
                if (!new_sock->file) {
                        new_sock->file = kzalloc(
                                        sizeof(struct file), GFP_KERNEL);

For one thing, as far as I can see it'not true - sctp does *not* depend on
socket->file being non-NULL; it does, in one place, check socket->file->f_flags
for O_NONBLOCK, but there it treats NULL socket->file as "flag not set".
Which is the case here anyway - the fake struct file created in
__iscsi_target_login_thread() (and in iscsi_target_setup_login_socket(), with
the same excuse) do *not* get that flag set.

Moreover, it's a bloody serious violation of a bunch of asserts in VFS;
all struct file instances should come from filp_cachep, via get_empty_filp()
(or alloc_file(), which is a wrapper for it).  FWIW, I'm very tempted to
do this and be done with the entire mess:

Signed-off-by: Al Viro 
Cc: Andy Grover 
Cc: Hannes Reinecke 
Cc: Christoph Hellwig 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: Add generation of LOGICAL BLOCK ADDRESS OUT OF RANGE

2012-08-09T15:22:35+00:00

commit e2397c704429025bc6b331a970f699e52f34283e upstream.

Many SCSI commands are defined to return a CHECK CONDITION / ILLEGAL
REQUEST with ASC set to LOGICAL BLOCK ADDRESS OUT OF RANGE if the
initiator sends a command that accesses a too-big LBA.  Add an enum
value and case entries so that target code can return this status.

Signed-off-by: Roland Dreier 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

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

2012-07-17T00:10:17+00:00

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