On Tue, 2016-02-02 at 10:37 +0100, Christoph Hellwig wrote: > > @@ -282,6 +305,16 @@ static void core_tmr_drain_state_list( > > if (prout_cmd == cmd) > > continue; > > > > + sess = cmd->se_sess; > > + if (WARN_ON_ONCE(!sess)) > > + continue; > > + > > + spin_lock(&sess->sess_cmd_lock); > > + rc = __target_check_io_state(cmd); > > + spin_unlock(&sess->sess_cmd_lock); > > + if (!rc) > > + continue; > > + > > I still don't understand why we care about the session or sess_cmd_lock > here. There isn't anything in __target_check_io_state that relies > on them (except for the assert checking the lock). Like I said earlier: "I'm still working on -v3 series to handle se_session shutdown during this specific multi-port LUN_RESET case, and considering using the existing se_cmd->cmd_wait_set bit to signal when this special case happens. Currently ->sess_cmd_lock is held in target_release_cmd_kref() and target_sess_cmd_list_set_waiting() while checking and setting this value." -- 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