Re: [PATCH 1/1] iser-target: Fix handling of RDMA_CV_EVENT_ADDR_CHANGE

[Sagi Grimberg <sagi@grimberg.me>]

>>> 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.