While I'm rambling, there is still a condition that probably needs to be
addressed:  if the application event handler function disconnects the
cm_id that is handling the event, the iw_cm workq thread gets stuck
posting a IW_CM_EVENT_CLOSE to rdma_cm.  So the iw_cm workq thread is
stuck in cm_close_handler() calling cm_id_priv->id.cm_handler() which is
cma_iw_handler() which is blocked in cma_disable_callback() because the
application is currently running its event handler for this cm_id.  This
block is released when the application returns from its event handler
function.

But maybe cma_iw_handler() should queue the event if it cannot deliver it,
vs blocking the iw_cm workq thread?

Answering myself:  queueing the event seems to be a no-go because the rdma_cm
can return non-zero to the iw_cm to indicate it should destroy the iw_cm_id.
This cannot be done correctly if the event is queued/deferred.





--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html