------- Comment From b...@us.ibm.com 2017-07-31 11:57 EDT-------
The reason target: Fix unknown fabric callback queue-full errors is required is
because if ibmvscsi driver returns a non -EAGAIN or -ENOMEM error back to
target-core then outgoing responses are leaked. This case is seen in
ibmvscsis_write_pending, we added code to return 0 to address cases where if
client failed or response queue is down to just return success to LIO, since
they can't do anything about it. (This is part of ibmvscsis: Do not send
aborted task response patch) But for cases where we attempted to transfer the
data and it failed and we return a -EIO, target core would leak. Thus we need
the target-core fix to address the 2nd part of that issue.
static int ibmvscsis_write_pending(struct se_cmd *se_cmd)
{
struct ibmvscsis_cmd *cmd = container_of(se_cmd, struct ibmvscsis_cmd,
se_cmd);
struct scsi_info *vscsi = cmd->adapter;
struct iu_entry *iue = cmd->iue;
int rc;
/*
* If CLIENT_FAILED OR RESPONSE_Q_DOWN, then just return success
* since LIO can't do anything about it, and we dont want to
* attempt an srp_transfer_data.
*/
if ((vscsi->flags & (CLIENT_FAILED | RESPONSE_Q_DOWN))) {
pr_err("write_pending failed since: %d\n", vscsi->flags);
return 0;
}
rc = srp_transfer_data(cmd, &vio_iu(iue)->srp.cmd, ibmvscsis_rdma,
1, 1);
if (rc) {
pr_err("srp_transfer_data() failed: %d\n", rc);
return -EIO;
}
/*
* We now tell TCM to add this WRITE CDB directly into the TCM storage
* object execution queue.
*/
target_execute_cmd(se_cmd);
return 0;
}
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1689365
Title:
ibmvscsis: Do not send aborted task response
Status in The Ubuntu-power-systems project:
Incomplete
Status in linux package in Ubuntu:
Incomplete
Bug description:
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
As per comment #11, this requires sending manual abort signals to trigger the
bug.
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential]
Patches are confined to ibmvscsi driver and target driver.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1689365/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
