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. -- -- 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
