On Sun, 2011-11-06 at 09:13 +0100, Bart Van Assche wrote: > On Thu, Nov 3, 2011 at 8:52 PM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: > > @@ -2365,8 +2384,14 @@ static void srpt_release_channel_work(struct work_struct *w) > > sdev = ch->sport->sdev; > > BUG_ON(!sdev); > > > > - transport_deregister_session_configfs(ch->sess); > > - transport_deregister_session(ch->sess); > > + se_sess = ch->sess; > > + BUG_ON(!se_sess); > > + > > + target_splice_sess_cmd_list(se_sess); > > + target_wait_for_sess_cmds(se_sess, 0); > > + > > + transport_deregister_session_configfs(se_sess); > > + transport_deregister_session(se_sess); > > ch->sess = NULL; > > > > srpt_destroy_ch_ib(ch); > > This leaves the possibility open that ch->sess is used by > srpt_handle_new_iu() while transport_deregister_session() is in > progress. That's a race condition. > Is there already a way to quiesce incoming I/O for an channel before invoking srpt_release_channel()..? What about srpt_drain_channel()..? Otherwise, we need a way to signal to srpt_handle_new_iu() + rest of the incoming I/O path that srpt_release_channel() has already been invoked, and start bouncing new I/O requests while waiting for outstanding se_cmd to be released in target_wait_for_sess_cmds() before dropping the actual session. It seems like srpt_rdma_ch->state could be used to signal this if necessary, as it's already obtaining the lock via srpt_get_ch_state() in the incoming I/O path. Is there a better way of doing this..? Thanks, --nab -- 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
