linux/drivers/target, branch v3.6

target: go through normal processing for zero-length REQUEST_SENSE

2012-09-07T18:32:54Z

Now that spc_emulate_request_sense has been taught to process zero-length REQUEST SENSE correctly, drop the special handling of unit attention conditions from transport_generic_new_cmd. However, for now REQUEST SENSE will be the only command that goes through emulation for zero lengths. (nab: Fix up zero-length check in transport_generic_new_cmd) Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: support zero allocation length in REQUEST SENSE

2012-09-07T18:14:21Z

Similar to INQUIRY and MODE SENSE, construct the sense data in a buffer and later copy it to the scatterlist. Do not do anything, but still clear a pending unit attention condition, if the allocation length is zero. However, SPC tells us that "If a REQUEST SENSE command is terminated with CHECK CONDITION status [and] the REQUEST SENSE command was received on an I_T nexus with a pending unit attention condition (i.e., before the device server reports CHECK CONDITION status), then the device server shall not clear the pending unit attention condition." Do the transport_kmap_data_sg early to detect this case. It also tells us "Device servers shall not adjust the additional sense length to reflect truncation if the allocation length is less than the sense data available", so do not do that! Note that the err variable is write-only. Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: support zero-size allocation lengths in transport_kmap_data_sg

2012-09-07T18:10:32Z

In order to support zero-size allocation lengths, do not assert that we have a scatterlist until after checking cmd->data_length. But once we do this, we can have two cases of transport_kmap_data_sg returning NULL: a zero-size allocation length, or an out-of-memory condition. Report the latter using sense codes, so that the SCSI command that triggered it will fail. Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: fail REPORT LUNS with less than 16 bytes of payload

2012-09-07T18:09:14Z

SPC says: "The ALLOCATION LENGTH field is defined in 4.3.5.6. The allocation length should be at least 16. Device servers compliant with SPC return CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB when the allocation length is less than 16 bytes". Testcase: sg_raw -r8 /dev/sdb a0 00 00 00 00 00 00 00 00 08 00 00 should fail with ILLEGAL REQUEST / INVALID FIELD IN CDB sense does not fail without the patch fails correctly with the patch Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: report too-small parameter lists everywhere

2012-09-07T18:09:08Z

Several places were not checking that the parameter list length was large enough, and thus accessing invalid memory. Zero-length parameter lists are just a special case of this. Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: go through normal processing for zero-length PSCSI commands

2012-09-07T18:04:08Z

Right now, commands with a zero-size payload are skipped completely. This is wrong; such commands should be passed down to the device and processed normally. For physical backends, this ignores completely things such as START STOP UNIT. For virtual backends, we have a hack in place to clear a unit attention state on a zero-size REQUEST SENSE, but we still do not report errors properly on zero-length commands---out-of-bounds 0-block reads and writes, too small parameter list lengths, etc. This patch fixes this for PSCSI. Uses of transport_kmap_data_sg are guarded with a check for non-zero cmd->data_length; for all other commands a zero length is handled properly in pscsi_execute_cmd. The sole exception will be for now REPORT LUNS, which is handled through the normal SPC emulation. Signed-off-by: Paolo Bonzini Signed-off-by: Nicholas Bellinger

target: fix use-after-free with PSCSI sense data

2012-09-06T00:20:28Z

The pointer to the sense buffer is fetched by transport_get_sense_data, but this is called by target_complete_ok_work long after pscsi_req_done has freed the struct that contains it. Pass instead the fabric's sense buffer to transport_complete, and copy the data to it directly in transport_complete. Setting SCF_TRANSPORT_TASK_SENSE also becomes a duty of transport_complete. Signed-off-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger

target: simplify code around transport_get_sense_data

2012-09-06T00:20:19Z

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 Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger

target: move transport_get_sense_data

2012-09-06T00:19:46Z

We will be calling it from transport_complete_cmd, avoid forward declarations. No semantic change. Signed-off-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger

target: Check idr_get_new return value in iscsi_login_zero_tsih_s1

2012-08-27T06:27:08Z

This patch updates iscsi_login_zero_tsih_s1() usage for generating iscsi_session->session_index to properly check the return value from idr_get_new(), and reject the iSCSI login attempt with exception status ISCSI_LOGIN_STATUS_NO_RESOURCES in the event of a failure. Signed-off-by: Benjamin Wang Signed-off-by: Nicholas Bellinger