Re: Debugging scsi abort handling ?

Finn Thain
2014-08-29T10:15:36Z

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

> The command will only ever be re-issued once EH completes.

...

>
> But indeed, 'FAILED' is not very meaningful here, leaving the midlayer
> with no information about what happened to the command.
>
> Personally I would like to enforce this meaning on the eh_XXX callbacks:
> - upon each eh_XXX callback the LLDD clears any internal references
> to the command / command scope (ie eh_abort_cmd clears the
> references to the command, eh_lun_reset clears all internal
> references to commands to this ITL nexus etc.)
> This happens irrespective of the return code.
> - The eh_XXX callback shall return 'FAILED' if the respective
> TMF (or equivalent) could not be initiated.
> - The eh_XXX callback shall return 'SUCCESS' if the respective
> TMF (or equvalent) could be initiated.
> - After each eh_XXX callback control for this command / command
> scope is transferred back to the midlayer; the LLDD shall not
> assume the associated command structures to remain valid after
> that point.

Perhaps that last constraint should be relaxed to "After the final EH
callback (whether implemented or unimplemented by the host), command /
command scope is transferred back to the midlayer..."

A more severe TMF is probably mandatory (e.g. bus reset) but if the driver
author later added a milder one (e.g. bus device reset), your rule would
mean that the existing handler would then operate under new constraints,
which might cause surprises.

> [...] I'm tempted to enshrine this in the documentation;

It is helpful, thanks.

--