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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
