[openib-general] [PATCH 3/4] IB CM: register and handle COMM_EST events on a QP

[Sean Hefty]

>> @@ -1015,20 +1089,33 @@ int ib_send_cm_req(struct ib_cm_id *cm_i
>>  	cm_id_priv->local_ack_timeout =
>>  				cm_req_get_primary_local_ack_timeout(req_msg);
>>
>> +	cm_id_priv->timewait_info->local_ca_guid = req_msg->local_ca_guid;
>> +	cm_id_priv->timewait_info->local_qpn = cm_id_priv->local_qpn;
>> +	spin_lock_irqsave(&cm.lock, flags);
>> +	if (cm_insert_local_qpn(cm_id_priv->timewait_info))
>> +		ret = -EADDRINUSE;
>> +	spin_unlock_irqrestore(&cm.lock, flags);
>
>why bother doing it here? can't the race happen only on the passive side
>of the connection?

The race can only happen on the passive side, but... for peer to peer
connections, we won't know which side is passive until later, and this tracks
the local QPN as part of timewait now.  (Note that peer to peer support requires
more work.)

>Just to make sure, following reading the code/patch i understand the
>case where the RTU does appear following the event is handled, what
>would happen in this case is that an EINVAL status would be returned by
>cm_rtu_handler to cm_work_handler and that's all.

Correct.

- Sean