On Mon, 2017-09-18 at 21:55 -0400, Keith Busch wrote: > The only way to complete that request now is if the timeout > handler returns BLK_EH_HANDLED, but the scsi-mq abort path returns > BLK_EH_NOT_HANDLED on success (very few drivers actually return > BLK_EH_HANDLED). > > After the timeout handler runs, it's once again possible for the driver to > complete the request if it returned BLK_EH_RESET_TIMER, but if the driver > already completed the command during the timeout handler, how is the > driver supposed to know it needs to complete the request a second time? Hello Keith, If you have a look at scmd_eh_abort_handler() then you will see that it either calls scsi_queue_insert(), scsi_finish_command() or scsi_eh_scmd_add(). scsi_queue_insert() reinserts the request. scsi_eh_scmd_add() wakes up the error handler thread to perform further error handling escalation. scsi_finish_command() calls scsi_end_request(). That last function in turn calls __blk_mq_end_request(). __blk_mq_end_request() does not check REQ_ATOM_COMPLETE. Sorry but the summary is that I do not agree with you that the SCSI core can lose requests. Bart.
