RE: iSCSI: aborting an immediate command with ABORT TASK

["Tony Battersby" <tonyb@cybernetics.com>]

Let me break it down:

From the initiator's perspective:
1) Send an immediate command with ITT = 22 and CmdSN = 7 on connection A
2) Send a non-immediate command with CmdSN = 7 on connection B
3) Send an immediate ABORT TASK command with Referenced Task Tag = 22 and
RefCmdSN = 7 and CmdSN = 8

From the target's perspective:
4) ExpCmdSN is 7
5) Receive the immediate command with ITT = 22 and CmdSN = 7 on connection A
6) Send the response to the immediate command from step 5 and free its
resources
7) Receive the immediate ABORT TASK command with Referenced Task Tag = 22
and RefCmdSN = 7 and CmdSN = 8 on connection A
8) Since no task exists with ITT = 22, and RefCmdSN is within the valid
CmdSN window, and RefCmdSN is less than the CmdSN of the ABORT TASK command,
consider CmdSN 7 received and set ExpCmdSN to 8
9) Receive the non-immediate command with CmdSN = 7 on connection B and
silently discard it because it is outside the valid CmdSN window.

In summary:
10) The end result is that the target aborted the wrong command.

Specifically, which one of these steps can't happen, and why?  AFAIK, this
_can_ happen in my current target iSCSI implementation.  If I am missing
something, then my implementation may be broken and I would like to fix it;
if I am not missing something, then there may be a real but fixable problem
with the way ABORT TASK works.

Tony

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 9:56 AM
To: tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK



Again no - there was no hole filed and the second 7 gets through. Julo


"Tony Battersby" <tonyb@cybernetics.com>
05/09/02 16:23
Please respond to tonyb

        To:        Julian Satran/Haifa/IBM@IBMIL, <Black_David@emc.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: aborting an immediate command with ABORT
TASK




From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 8:27 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

> The next command can't be clobered. Abort Task acts on command  up to 6
> (included) but not 7- and it has to be on the same connection as the
> aborted command. That insures that it will abort the first immediate but
> not the non-immediate after.

Ok, here's the gotcha:

The initiator sends a non-immediate command with CmdSN 7 on a different
connection before sending the immediate ABORT TASK for the first immediate
command.  The ABORT TASK is sent on the same connection as the immediate
command with CmdSN 7 to be aborted, but a different connection than the
non-immediate command with CmdSN 7.  The ABORT TASK will carry a CmdSN of 8,
and the target may receive the ABORT TASK before it receives the
non-immediate command with CmdSN 7, because they are sent on different
connections.  If this happens, the target considers CmdSN 7 received and
then discards the non-immediate command with CmdSN 7 when it finishes
receiving it on the other connection.

Tricky, tricky, tricky...

Tony