On Tue, Dec 10, 2019 at 12:47:57PM +0100, Martin Wilck wrote: > Hi Bart, > > On Mon, 2019-12-09 at 10:02 -0800, Bart Van Assche wrote: > > Since the SCSI core does not reuse the tag of the SCSI command that > > is > > being aborted by .eh_abort() before .eh_abort() has finished it is > > not > > necessary to check from inside that callback whether or not the SCSI > > command > > has already completed. Instead, rely on the firmware to return an > > error code > > when attempting to abort a command that has already completed. > > Additionally, > > rely on the firmware to return an error code when attempting to abort > > an > > already aborted command. > > Do we have evidence that the firmware can truly be relied upon in this > respect? It's at least not impossible that the FW (or some version of > it) relies on the driver not trying to abort commands that have been > aborted or completed already, and crashes if that assumption is > violated. > Hi Martin, IMO yes, FW spec defines the behavior mentioned by Bart in the commit message. So an Abort IOCB is going to be completed by FW (including an error if the command was already aborted) or timed out if FW is down. Thanks, Roman
