As sas_eh_finish_cmd() routine is used when a sas task is marked succfully recovered(or the device is marked OFFLINE), then the corresponding task_done will be invoked after SAS_TASK_STATE_ABORTED is unmasked. Whatever sas_scsi_task_done() or sas_ata_task_done() got invoked, it will translate task_status to scsi_cmnd->request, free the sas_task structure and invoke task_done, the problem is, after task_done(), scsi_eh_finish_cmd() will still add the cmd to sas_ha->eh_done_q, and in the coming scsi_eh_flush_done_q(), it will retry the command or invoke scsi_finish_command() to finish the request again. Take a timeout SSP request in the race condition for example, if the request is returned prior to lldd_abort_task() and set SAS_TASK_STATE_DONE, the lldd_abort_task() handler will do nothing but return TASK_IS_DONE in sas_scsi_find_task(), later sas_eh_finished_cmd() will get invoked and unset SAS_TASK_STATE_ABORTED mask to let sas_scsi_task_done() in, since it's a good response and the request will be finished succfully.But current strategy will add the scsi_cmnd to sas_ha->eh_done_q after task_done() is performed. Then if possibe, we may scsi_queue_insert(scmd, SCSI_MLQUEUE_EH_RETRY) in scsi_eh_flush_done_q(). I meet the condition and sometime the system hangs. Did I miss something? -- Regards, Ying Chu -- 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
