On Tue, 2011-12-20 at 09:01 +0000, Bart Van Assche wrote: > On Mon, Dec 19, 2011 at 10:51 PM, David Dillow <dillowda@xxxxxxxx> wrote: > > I haven't parsed it all out from your changes just yet, but I think part > > of the reason you may have had problems with req->scmd being null in > > srp_handle_recv() is due to a new race between the tear down of the > > connection and continuing to process completion notifications. > > The resources used by the QP completion handler are the srp_target > port data structure and the QP data structure. And as you can see in > srp_remove_target(), the scsi_host_put() call is invoked after > srp_disconnect_target(). That last function waits for the DREP > notification from the IB CM. That should guarantee that no IB > completions arrive during or after the scsi_host_put() call. Or did I > miss something ? What keeps the srp_recv_completion() --> srp_handle_recv() --> srp_process_rsp() --> etc. call chain from racing with srp_reconnect_target()? It looks like the srp_reset_req() in srp_reconnect_tartget() could race with srp_process_rsp() if receive completions continue to be processed after a send failure, but perhaps it is I who is missing something. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- 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
