>> AFAIK the existing listening ID remains, the notification is >> informative, it doesn't indicate any CM state has changed. > > Gleb, can you confirm that? In my case, when 2 physical interfaces are bonded and the cable is pulled out for one of them, the RDMA_CM_EVENT_ADDR_CHANGE event is processed 2 times. 1 for condition isert_np->cm_id == cma_id isert_np_cma_handler() is called The old cma_id is destroyed and a new one is created 2 for condition isert_np->cm_id != cma_id isert_disconnected_handler() is called As I understand it in this case, RDMA_CM_EVENT_ADDR_CHANGE is not just an informative event. It is needed to recreate the isert connection (struct isert_conn) for the standby path. I may be wrong, but the creation of a 'struct isert_conn' is initiated in isert_rdma_accept(), that is, when the cma_id is created. Therefore, it seems to me that you need to recreate cma_id, otherwise who will recreate isert_conn?