2. Should ib_create_cm_id check return an error if cm_handler == NULL just to make sure ?
Personally, I don't think it's worth this check for kernel clients, unless we want to start checking for NULL parameters everywhere.
Incoming REQs currently use this capability anyhow.
Incoming REQs use the cm_handler associated with the listen request.
While on the CM, I did look at the issue of calling the API out of order that you had pointed out before (which could result in accessing a NULL port pointer). I'm not convinced that a simple check for a NULL port pointer covers all potential problems. For example, I'm not sure how well the codebase will handle the dynamic removal of a device while users are attempting to access the device.
We may need to handle this at some point. Guess the changes may be larger if/when we get there.
One of the side effects of changing the CM from using a pointer to a QP to just the QPN is that the CM can no longer rely on the device being around. And I agree, this will need to be handled at some point, but may not be a huge issue as long as the client is reasonable and disconnects before destroying their QP.
It looks like sending private data in REQ/REP/RTU, but incoming private data isn't handled on the receiving side.
The private_data is given to the user in the cm_event structure. Look for work->cm_event.private_data = in cm_format_req_event, cm_format_rep_event, and cm_rtu_handler. Note that the private_data is only available while in the CM event callback.
Also, in cm_process_send_error(), where the handler is called
cm_id_priv->id.cm_handler(&cm_id_priv->id, &cm_event);
might that callback request the CM ID destruction ? If so, some code is missing to handle this.
Yep - this is a bug. Send errors should probably be handled using the same cm_process_work routine that the receive handling goes through. I'll generate a patch for this, but it'll take me a few days, unless this is urgent.
- 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
