Re: Debugging scsi abort handling ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux