On Mon, Nov 28, 2011 at 12:03 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > The SRP login failure path in srpt_cm_req_recv() is already calling > srpt_destroy_ch_ib() -> kthread_stop(ch->thread) to trigger the call to > srpt_release_channel_work() when shutting down srpt_compl_thread(). > > This is currently because srpt_create_ch_ib() has already been called to > start compl thread while various failures may still prevent a successful > SRP login from occuring. > > So while the patch fixes an OOPs I've been seeing with your original > 'Fix Last WQE handling' patch during SRP login failure, I'm wondering if > the better changing is to try to move kthread_run() out of > srpt_create_ch_ib(), and wait until after ib_send_cm_rep() has completed > before starting up srpt_compl_thread(). > > Any thoughts..? The current error path in srpt_cm_req_recv() is racy because e.g. transport deregistration in that function can run concurrently with srpt_release_channel_work(). One possible way to address this is to invoke srpt_close_ch() to clean up channel resources after the completion thread has been created instead of deallocating each channel resource individually. Deferring thread creation until after ib_send_cm_rep() doesn't look fine to me: SRP requests can start arriving as soon as the ready-to-receive state has been reached. Bart. -- 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
