--- James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote:
> On Tue, 2006-05-16 at 11:41 -0400, Jeff Garzik wrote:
> > You miss the fact that the timer may have already fired, in which
> > completing a command gets you...... not a damned thing. scsi_done()
> > will simply return, if the timeout has fired. This has always been an
> > annoying problem to work around.
>
> No ... in that case the eh is already active, and your API does this:
>
> void scsi_req_abort_cmd(struct scsi_cmnd *cmd)
> {
> if (!scsi_delete_timer(cmd))
> return;
> ^^^^^^^
> scsi_times_out(cmd);
> }
>
> Which likewise does nothing if the timer has already fired, so they both
> have the same effect.
I think I just explained this. Let me try again.
They don't both have the same effect. What you're suggesting. calling done()
with status so that, EH can turn around and recover the command, as in this thread
and in this thread: http://marc.theaimsgroup.com/?l=linux-scsi&m=113833937421677&w=2,
_terminates_ the command nexus with the driver!
Secondly, this function, solves races between the transport telling you "I want
to abort this command" and the command timing out. When the driver get transport
notification that this command should be aborted, it doesn't need to care
where and in what state with SCSI Core the command is. As long as it has nexus
it can call this function and then the command would be recovered with
ABORT TASK or another TMF as it pertinent to the transport.
Calling scsi_req_abort_cmd() _guaranees_ that this command would be recovered
either way. This gives LLDD and interconnects guarantee that ABORT TASK
would be called and then they can do recovert for the command/device.
Luben
-
: 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
