Re: [PATCH v3] ibmvscsis: Do not send aborted task response

2017-05-07 Thread Nicholas A. Bellinger
On Fri, 2017-05-05 at 14:17 -0500, Bryant G. Ly wrote:
> 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.
> 
> Cc:  # v4.8+
> Signed-off-by: Bryant G. Ly 
> Signed-off-by: Michael Cyr 
> ---
>  drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 114 
> ---
>  drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h |   2 +
>  2 files changed, 91 insertions(+), 25 deletions(-)
> 

Applied.

Thanks Bryant + Michael.



[PATCH v3] ibmvscsis: Do not send aborted task response

2017-05-05 Thread Bryant G. Ly
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.

Cc:  # v4.8+
Signed-off-by: Bryant G. Ly 
Signed-off-by: Michael Cyr 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 114 ---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h |   2 +
 2 files changed, 91 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 0f80779..d390325 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -1170,6 +1170,7 @@ static struct ibmvscsis_cmd 
*ibmvscsis_get_free_cmd(struct scsi_info *vscsi)
cmd = list_first_entry_or_null(>free_cmd,
   struct ibmvscsis_cmd, list);
if (cmd) {
+   cmd->flags &= ~(DELAY_SEND);
list_del(>list);
cmd->iue = iue;
cmd->type = UNSET_TYPE;
@@ -1749,45 +1750,79 @@ static void srp_snd_msg_failed(struct scsi_info *vscsi, 
long rc)
 static void ibmvscsis_send_messages(struct scsi_info *vscsi)
 {
u64 msg_hi = 0;
-   /* note do not attmempt to access the IU_data_ptr with this pointer
+   /* note do not attempt to access the IU_data_ptr with this pointer
 * it is not valid
 */
struct viosrp_crq *crq = (struct viosrp_crq *)_hi;
struct ibmvscsis_cmd *cmd, *nxt;
struct iu_entry *iue;
long rc = ADAPT_SUCCESS;
+   bool retry = false;
 
if (!(vscsi->flags & RESPONSE_Q_DOWN)) {
-   list_for_each_entry_safe(cmd, nxt, >waiting_rsp, list) {
-   iue = cmd->iue;
+   do {
+   retry = false;
+   list_for_each_entry_safe(cmd, nxt, >waiting_rsp,
+list) {
+   /*
+* Check to make sure abort cmd gets processed
+* prior to the abort tmr cmd
+*/
+   if (cmd->flags & DELAY_SEND)
+   continue;
 
-   crq->valid = VALID_CMD_RESP_EL;
-   crq->format = cmd->rsp.format;
+   if (cmd->abort_cmd) {
+   retry = true;
+   cmd->abort_cmd->flags &= ~(DELAY_SEND);
+   }
 
-   if (cmd->flags & CMD_FAST_FAIL)
-   crq->status = VIOSRP_ADAPTER_FAIL;
+   /*
+* If CMD_T_ABORTED w/o CMD_T_TAS scenarios and
+* the case where LIO issued a
+* ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST
+* case then we dont send a response, since it
+* was already done.
+*/
+   if (cmd->se_cmd.transport_state & CMD_T_ABORTED 
&&
+   !(cmd->se_cmd.transport_state & CMD_T_TAS)) 
{
+   list_del(>list);
+   ibmvscsis_free_cmd_resources(vscsi,
+cmd);
+   } else {
+   iue = cmd->iue;
 
-   crq->IU_length = cpu_to_be16(cmd->rsp.len);
+   crq->valid = VALID_CMD_RESP_EL;
+   crq->format = cmd->rsp.format;
 
-