quoted

quoted

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?

There are two handlers in question here, the listener cm_id and
the connection cm_id. The connection cma_id should definitely trigger
disconnect and resource cleanup. The question is should the listener
cma_id (which maps to the isert network portal - np) recreate the
cma_id in this event.