Re: Debugging scsi abort handling ?

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

Hi,

On 08/28/2014 02:04 PM, Hannes Reinecke wrote:
> On 08/25/2014 01:15 PM, Paolo Bonzini wrote:
>> Il 25/08/2014 12:28, Bart Van Assche ha scritto:
>>>
>>>  From SPC-4: "7.5.8 Control mode page [ ... ] A task aborted status (TAS)
>>> bit set to zero specifies that aborted commands shall be terminated by
>>> the device server without any response to the application client. A TAS
>>> bit set to one specifies that commands aborted by the actions of an I_T
>>> nexus other than the I_T nexus on which the command was received shall
>>> be completed with TASK ABORTED status (see SAM-5)."
>>
>> Note the "aborted by the actions of an I_T nexus other than the I_T
>> nexus on which the command was received".
>>
>> In practice, this means that TASK ABORTED should only happen if you use
>> the CLEAR TASK SET tmf and TST is not set to 001b (i.e. _not_ to "per
>> I_T nexus") in the Control mode page.  It should never happen for a pen
>> drive.
>>
>> 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.

Interesting, those very bad things may very well be exactly the things
some uas users are seeing. But this sounds racy, I can stop a command
from completing as the very first thing inside eh_abort, but I cannot
stop it from completing when the scsi core is getting ready to call
eh_abort, but eh_abort is not yet called.

Is there some flag I should check before calling scsi_done to avoid this
race? And if so which locks should I hold (and why does scsi_done not do
this check itself) ?

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

I'm fine with not calling scsi_done from eh_abort, but I cannot guarantee
that another thread will not complete the cmnd in the mean time before hand.

Thanks for your input!

Regards,

Hans