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 (?) > Either that or return 'FAILED' for any later eh_XXX function until the > internal references can be cleared up. So if a command may or may not "exist" after eh_abort_handler() returns control to the mid-layer (regardless of SUCCESS or FAILURE), then the LLD has to be careful about keeping track of which commands were aborted, if those commands are still in the process of cleanup when eh_abort_handler() returns. It's hard to see how that can work when command pointers are only unique while a command "exists". In effect, this would mean that EH functions cannot return at all, until the relevant command(s) are completely forgotten by the LLD; and that means the LLD itself may have to escalate abort -> device reset -> bus reset -> etc instead of simply returning FAILED. -- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
