Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

From: "Julian Satran" <[email-masked]>
Date: Thu, 5 Sep 2002 15:26:33 +0300

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.

As for the mapping - you are right - I'll mark it for the final edit 
(whenever that happens).

Julo

[email-masked]
Sent by: [email-masked]
05/09/02 09:50

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec 
requires
> the target to plug a hole which does not exist, which is the problem 
that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following 
statements:

                 CmdSN always contains the number to be 
      assigned to the next Command PDU.

   Commands meant for immediate delivery are marked with an immediate 
   delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

     b)  if the Referenced Task Tag does not identify an existing task 
     but if the CmdSN indicated by the RefCmdSN field in the Task Man-
      agement function request is within the valid CmdSN window (between 
      MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received 
      and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Tony Battersby" <[email-masked]>
Date: Thu, 5 Sep 2002 09:23:43 -0400

From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, September 05, 2002 8:27 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

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

---

From: Paul Koning <[email-masked]>
Date: Thu, 5 Sep 2002 09:49:11 -0400

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

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

If the abort has to be sent on the same connection as the command
being aborted, then it cannot overtake an immediate command preceding
it.  At least not in the network stack...  So that seems to eliminate
the case that David was worrying about. 

    paul