Hi, On 08/29/2014 12:30 PM, Hannes Reinecke wrote: > On 08/29/2014 12:14 PM, Finn Thain wrote: >> >> On Fri, 29 Aug 2014, Hannes Reinecke wrote: >> >>> On 08/29/2014 06:39 AM, Finn Thain wrote: >>>> >>>> On Thu, 28 Aug 2014, Hannes Reinecke wrote: >>>> >>>>> What might happen, though, that the command is already dead and gone >>>>> by the time you're calling ->scsi_done() (if you call it after >>>>> eh_abort). So there might not _be_ a command upon which you can call >>>>> ->scsi_done() to start with. >>>>> >>>>> Hence any LLDD need to clear up any internal references after a call >>>>> to eh_XXX to ensure it doesn't call ->scsi_done() an in invalid >>>>> command. >>>>> >>>>> So even if the LLDD returns 'FAILED' upon a call to eh_XXX it >>>>> _still_ needs to clear up the internal reference. >>>> >>>> This is a question that has been bothering me too. If the host's >>>> eh_abort_cmd() method returns FAILED, it seems the mid-layer is liable >>>> to re-issue the same command to the LLD (?) >>>> >>> No. >>> FAILED for any eh_abort_cmd() means that the TMF hasn't been sent. >> >> Makes sense, though it appears to contradict this advice about returning >> SUCCESS in some situations: >> http://marc.info/?l=linux-scsi&m=140923498632496&w=2 >> > Well, if the LLDD detects an invalid command (ie if it cannot find any internal command matching the midlayer command) that's an automatic success, obviously. > > So we should rephrase things to: > > - The eh_XXX callback shall return 'SUCCESS' if the respective > TMF (or equvalent) could be initiated or if the matching command > reference has already been completed by the LLDD. Otherwise > the eh_XXX callback shall return 'FAILED'. Your talking about "could be initiated", so that means that at this point the abort does not yet have to be completed, do I get that right? What should the LLDD then do when the abort finishes, call eh_scsi_done on the cmnd ? What about the abort never finishing (timeout), does the mid layer track this, or should the LLDD do that? 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
