> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
