>> @@ -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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
