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

From: [email-masked]
Date: Tue, 3 Sep 2002 19:20:55 -0400

Tony,

> > 1) The possible out-of-order arrival of an abort and the immediate
command
> > upon which it is supposed to act
> > 2) The race between an immediate command finishing normally 
> > (causing the target to free the command and forget its associated ITT)
> >  and the initiator aborting it
> > 3) The immediate command to be aborted may have been 
> > discarded due to a header digest error
> 
> Replying to myself, #1 should actually not happen because of the
requirement
> for an ABORT TASK to be issued on the same connection to which the task
> being acted upon is currently allegiant.  Points #2 and #3 are still valid
> though.

That's not correct.  In case 2) the ABORT TASK always succeeds no
matter how the race turns out - SAM-2 Section 6.2 says:

	If the logical unit supports this function, a response of
	FUNCTION COMPLETE shall indicate that the task was aborted
	or was not in the task set.

The words "or was not in the task set" are the crucial ones.  In
case 2), the ABORT TASK always returns FUNCTION COMPLETE, and there may
or may not be a response from the aborted task prior to that FUNCTION
COMPLETE, but there MUST NOT be one afterwards.

The analysis for 3) is similar - if the command to be aborted was
discarded due to a header digest error, the ABORT TASK still succeeds
because the task "was not in the task set".

> Another possibility is that the target is in the process of sending
> a Reject PDU for the immediate command to be aborted when it receives the
> ABORT TASK command, and the target implementation doesn't check the ITT
from
> a PDU that it has chosen to reject.

Yet another similar analysis - the ABORT TASK succeeds whether it was
received before or after the Reject PDU was sent.  Similar to the above,
the Reject PDU MUST NOT follow the response to the ABORT TASK.

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: Wed, 4 Sep 2002 09:11:39 -0400

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, September 03, 2002 7:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> Tony,
>

> COMPLETE, but there MUST NOT be one afterwards.

I am not really concerned about the response code to the ABORT TASK.  My
concern is that the initiator may end up plugging a CmdSN hole when it
shouldn't.  From Section 9.6.1 (draft 15),

"...targets must consider the CmdSN received and return the "Function
complete" response."

I don't have a problem with returning the "Function complete" response.  I
do have a problem with the target considering the CmdSN received if the
initiator intended to abort an immediate command.

Tony