Receiving a SCSI response after abort task was sent

Receiving a SCSI response after abort task was sent

[Erez Zilber]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Receiving a SCSI response after abort task was sent

[Ishai Rabinovitz]

On Sun, Jul 02, 2006 at 01:51:51PM +0300, Erez Zilber wrote:
> 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
> -- 
> 

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

Re: Receiving a SCSI response after abort task was sent

[Erez Zilber]

Ishai Rabinovitz wrote:
> On Sun, Jul 02, 2006 at 01:51:51PM +0300, Erez Zilber wrote:
>   
>> 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
>> -- 
>>
>>     
>
> 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.
>
>
>   
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

Re: Receiving a SCSI response after abort task was sent

[Ishai Rabinovitz]

On Sun, Jul 02, 2006 at 04:47:58PM +0300, Erez Zilber wrote:
> Ishai Rabinovitz wrote:
> >On Sun, Jul 02, 2006 at 01:51:51PM +0300, Erez Zilber wrote:
> >  
> 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

Re: Receiving a SCSI response after abort task was sent

[James Smart]

Erez Zilber wrote:
> 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). 

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.

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

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