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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to