linux-toradex.git/drivers/target/target_core_cdb.c, branch v3.4.2

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

2012-03-16T02:14:48+00:00

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: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

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

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

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

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

target: Fix up handling of short INQUIRY buffers

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

If the initiator sends us an INQUIRY command with an allocation length
that's shorter than what we want to return, we're simply supposed to
truncate our response and return what the initiator gave us space for,
without signaling any error.  Current target code has various tests that
don't fill out the full response if the buffer is too short and
sometimes return errors incorrectly.

Fix this up by allocating a bounce buffer for INQUIRY responses if we
need to, ie if we have cmd->data_length too small as well as
SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC set in cmd->se_cmd_flags -- for most
fabrics, we always allocate at least a full page, but for tcm_loop we
may have a small buffer coming directly from the SCSI stack.

This lets us delete a lot of cmd->data_length checking, and also makes
our INQUIRY handling correct per SPC in a lot more cases.

Signed-off-by: Roland Dreier 
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger

target: accept REQUEST_SENSE with 18bytes

2012-02-07T06:32:39+00:00

WindowsXP+BOT issues a MODE_SENSE request with page 0x1c which is not
suppoerted by target. Target rejects that command with
TCM_INVALID_CDB_FIELD, so far so good. On BOT I can't send the SENSE
response back, instead I can only reply that an error occured. The next
thing happens is a REQUEST_SENSE request with 18 bytes length. Since the
check here is more than 18 bytes I have to NACK that request as well.
This is not really required: We check for some additional room, but we
never use it. The additional length is set to 0xa so the total length is
0xa + 8 = 18 which is fine with my 18 bytes.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger

target: Fail INQUIRY commands with EVPD==0 but PAGE CODE!=0

2012-01-18T08:35:59+00:00

My draft of SPC-4 says:

    If the PAGE CODE field is not set to zero when the EVPD bit is set
    to zero, the command shall be terminated with CHECK CONDITION
    status, with the sense key set to ILLEGAL REQUEST, and the
    additional sense code set to INVALID FIELD IN CDB.

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

target: Return correct ASC for unimplemented VPD pages

2012-01-18T08:35:58+00:00

My draft of SPC-4 says:

    If the device server does not implement the requested vital product
    data page, then the command shall be terminated with CHECK CONDITION
    status, with the sense key set to ILLEGAL REQUEST, and the
    additional sense code set to INVALID FIELD IN CDB.

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

target: Allow control CDBs with data > 1 page

2012-01-18T08:35:58+00:00

We need to handle >1 page control cdbs, so extend the code to do a vmap
if bigger than 1 page. It seems like kmap() is still preferable if just
a page, fewer TLB shootdowns(?), so keep using that when possible.

Rename function pair for their new scope.

Signed-off-by: Andy Grover 
Cc: 
Signed-off-by: Nicholas Bellinger

target: Set response format in INQUIRY response

2011-12-14T11:38:28+00:00

Current SCSI specs say that the "response format" field in the standard
INQUIRY response should be set to 2, and all the real SCSI devices I
have do put 2 here.  So let's do that too.

Signed-off-by: Roland Dreier 
Cc: stable@kernel.org
Signed-off-by: Nicholas Bellinger