On Fri, 2017-02-10 at 01:11 +0000, Bart Van Assche wrote: > On Thu, 2017-02-09 at 17:06 -0800, Nicholas A. Bellinger wrote: > > qla2xxx must wait until the CTIO hw completion for the outstanding WRITE > > transfer is finished, before the abort can continue processing. > > > > This change and the previous changes ignore all of that. > > Incorrect. My patches wait for the CTIO hw completion. > Looking at your -v4 and -v5 changes, this doesn't appear to be the case. Let's walk through how it works in the existing code, yes..? So a LUN_RESET occurs in tmr_wq context for a particular se_cmd and CMD_T_ABORTED is set, while a qla2xxx CTIO for WRITE transfer is still outstanding to ISP HW. Since the se_cmd is !CMD_T_ACTIVE while it's owned by the fabric driver once se_cmd->se_tfo->write_pending() has been called to perform the transfer, the normal transport_wait_for_tasks() code-path will not block on se_cmd->t_transport_stop_cmp because CMD_T_ACTIVE is not set. >From there, transport_cmd_finish_abort() proceeds to block waiting for CTIO interrupt completion in tcm_qla2xxx_handle_data_work() to occur, and subsequently completes se_cmd->t_transport_stop_cmp to allow CMD_T_ABORT in tmr_wq context to proceed, et al. With v4 and v5 changes, tmr_wq blocks on a new cmd->[finished,complete] completion after CMD_T_STOP has been set. CTIO interrupts fire for the outstanding WRITE transfer, and tcm_qla2xxx_handle_data_work() returns immediately for the aborted qla_tgt_cmd->se_cmd. How can that possibly allow the aborted command to continue processing..? -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
