Sean Hefty wrote: > Register the IB CM to receive and process communication established > events on a QP. This requires tracking connections using local QPNs > as part of timewait handling. > > Signed-off-by: Sean Hefty <[EMAIL PROTECTED]> > --- > Index: core/cm.c > =================================================================== > --- core/cm.c (revision 8629) > +++ core/cm.c (working copy) > @@ -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? 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. Or. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
