ok. I'll try refing the iw_cm_id before upcalling into the cma. That should have the same effect.
On Thu, 2006-01-26 at 11:15 -0800, Sean Hefty wrote: > Steve Wise wrote: > > I'm running the kernel cmatose. The server side gets a connect request, > > but the init_node() returns an error because the qp create fails. The > > cmatose module then rejects the connect request on that connect request > > upcall. Concurrently (on the main work thread running run_server()), > > cmatose calls rdma_destroy_id() on the listening id. The destroy > > happens before the connect request upcall thread finishes (SMP :). > > rdma_destroy_id() must block while there is a callback outstanding against > the > id being destroyed. This is true when pushed down to the lower level > IB/iWarp > code. The reference counting needs to be handled by the module invoking the > callback, not the module being called. > > Imagine if the callback is about to be invoked when the user calls > rdma_destroy_id(). rdma_destroy_id() completes, the user releases their > memory, > then the callback hits there code. The user's context is already invalid, so > a > reference doesn't help. > > > I _think_ the solution is to bump the listen_id refcnt at the top of > > cma_req_handler() and iw_conn_req_handler(), and do a cma_deref_id() on > > the listen_id at the end of the functions. > > See above. If the listen_id can be destroyed while the user is in > cma_req_handler(), then it can be destroyed before the reference can be taken. > > Does the iWarp CM take a reference on the corresponding listen_id before > invoking a connect request callback? > > - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
