On Fri, 28 Mar 2014, James Bottomley wrote:
> This is a set of three patches we agreed to a while ago to eliminate a
> USB deadlock. I did rewrite the first patch, if it could be reviewed
> and tested.
I tested all three patches under the same conditions as before, and
they all worked correctly.
In the revised patch 1, the meaning of SCSI_EH_ABORT_SCHEDULED isn't
entirely clear. This boils down to two questions, which I don't
know the answers to:
What should happen in scmd_eh_abort_handler() if
scsi_host_eh_past_deadline() returns true and thereby
prevents scsi_try_to_abort_cmd() from being called?
The flag wouldn't get cleared then.
What should happen if some other pathway manages to call
scsi_try_to_abort_cmd() while scmd->abort_work is still
sitting on the work queue? The command would be aborted
and the flag would be cleared, but the queued work would
remain. Can this ever happen?
Maybe scmd_eh_abort_handler() should check the flag before doing
anything. Is there any sort of sychronization to prevent the same
incarnation of a command from being aborted twice (or by two different
threads at the same time)? If there is, it isn't obvious.
(Also, what's going on at the start of scsi_abort_command()? Contrary
to what one might expect, the first part of the function _cancels_ a
scheduled abort. And it does so without clearing the
SCSI_EH_ABORT_SCHEDULED flag.)
Maybe in all these scenarios, the command is doomed to fail anyway so
these questions don't make any real difference. I don't know...
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
