Receiving a SCSI response after abort task was sent

Hi,

I have a question about aborting tasks: when an initiator sends "abort task" to the target, it is possible that the target will send a SCSI response for the same task before receiving the abort task (I guess that the target won't send a task management response for the abort task). What should the initiator do with the SCSI response? Is the host that issued the abort task willing to receive a SCSI response for that task? Is it willing to receive only a task management response for the abort task?

This message was also sent to ips mailing list.

Thanks

____________________________________________________________

Erez Zilber | 972-9-971-7689

Software Engineer, Storage Team

Voltaire – _The Grid Backbone_

__

www.voltaire.com <http://www.voltaire.com/>


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

In my opinion the initiator should work with the response and call the done callback of this SCSI command.
This is the way we implement it in SRP: When we get a response for the task we set a bit indicting that this command was done.
In the code that sends the task management and waits for response, we check after getting the response if this flag is set. If the flag is set we call the done callback. If it is not set, we set the result of the command to DID_ABORT.

Ishai Rabinovitz

Did you find any ref for this in SAM3? The only thing that I was able to find there is that a target that receives an "abort task" has to send a task management response even if it has already sent a SCSI response for that task.

Thanks
Erez

I'm using this feature (After the response to the ABORT I'm checking if I got a response to the original request meanwhile).
In any case I think it is more efficient to handle the response and not the abort.
It is safe for read requests. and I think it is safe also for write requests since the target must have handled the request before handling the abort (Otherwise there would have been no response to the request).

Does anyone see a problem with that (Maybe with Multipath)?

Ishai Rabinovitz

Yes - as the 2 may be in flight simultaneously (depending on the SCSI transport type). And yes, the target will respond to the task management response, but may tell you it failed or that the task didn't exist.

Well, this is macrocosm of other race conditions that can still exist within the software/driver/adapter. The recommended approach has been:
if the i/o completes (good or bad) before the task mgmt response, complete it with whatever response is appropriate (usually ignoring the fact that there was a request to abort it) - as you are reporting the true state of the io - which means if it changed media, you have a chance of knowing that above. In the abort handler, if the tmf completes indicating it couldn't find the i/o and the driver no longer has the i/o in it's queues, you would just return "success" to the request (an abort
of nothing is successful :). Keep in mind that this has another
implication that should be maintained - that of status from the i/o being returned prior to status of the tmf - whether the status is returned from an adapter, or by the driver.

-- james s