Re: Debugging scsi abort handling ?

Finn Thain
2014-08-29T04:40:53Z

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.

--