Re: Debugging scsi abort handling ?

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 08/28/2014 02:17 PM, Paolo Bonzini wrote:
> Il 28/08/2014 14:04, Hannes Reinecke ha scritto:
>>>
>>> Setting TASK ABORTED aside, the important part is that an abort can do
>>> one of two things:
>>>
>>> - complete the command, and then eh_abort should return after the driver
>>> has noticed the completion and called the ->scsi_done callback for the
>>> Scsi_Cmnd*.
>>>
>>> - abort the command, and then the driver should never call the
>>> ->scsi_done callback for the Scsi_Cmnd*.
>>>
>> In practice we rely on the latter behaviour; when ->scsi_done is called
>> while the command is under eh_abort _really bad things_
>> will happen.
>> As soon as eh_abort is called control is transferred back to the
>> SCSI midlayer, so any LLDD should never send completions for these
>> commands back to the midlayer.
> 
> No, this is wrong.  I think we have sorted it out a couple of months
> ago.  virtio-scsi for example (due to QEMU quirks) will do the former
> more often than not.
> 
> Ignoring scsi_eh_done which is just as harmless, 

scsi_eh_done is new to me. Should I ever use that, and if so when ?

> ->scsi_done does
> nothing more than calling blk_complete_request.  If the command is under
> abort, it has already been marked as complete by the block layer's
> timeout timer---see blk_rq_timed_out_timer and blk_rq_check_expired---or
> by blk_abort_request.
> 
> Then, blk_complete_request will do nothing because its call to
> blk_mark_rq_complete returns true.
> 
> All this, of course, as long as ->scsi_done is called _before_ eh_abort
> returns.

What about calling scsi_done after eh_abort if eh_abort returned FAILED?

Regards,

Hans