> -----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Paolo Bonzini > Sent: Wednesday, 21 May, 2014 3:34 PM > To: Mark Wu; linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: dangling pointers and/or reentrancy in > scmd_eh_abort_handler? > > Il 21/05/2014 16:16, Mark Wu ha scritto: > > Is it possible that when scsi_done is invoked, the scsi command or the > > request has been freed and then reallocated for a new I/O request? > Because > > of this the bit flag REQ_ATOM_COMPLETE becomes unreliable. Thanks! > > It is up to the driver to ensure that the interrupt handler will not > process the Scsi_Cmnd* after returning from the eh_abort_handler. If > you do this, what you say cannot happen. Otherwise you'll get a variety > of failures, the most common of which for me are OOPSes and a BUG in > blk_finish_request. > > Paolo Aborts don't always work; scsi_eh_abort_handler cannot promise that it aborted the command (unless it escalated to sending resets.) When the abort fails, scmd_eh_abort_handler just leaves it outstanding, and the error handler thread (scsi_error_handler function) must deal with it. If the abort succeeds, then scmd_eh_abort_handler calls scsi_finish_command. In SCSI terms, FUNCTION COMPLETE for ABORT TASK doesn't mean the command was present and aborted and won't be sending back status; if the device server already sent status for the command, the task manager also sends FUNCTION COMPLETE. Depending on the transport, there may be a race condition between the command status and the ABORT TASK response; the ABORT TASK response might get back first. I think that means scsi_eh_abort_handler's call to scsi_finish_command could happen during or after scsi_softirq_done has called scsi_finish_command. --- Rob Elliott HP Server Storage -- 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
