Hal Rosenstock wrote:
It seems possible that this is called prior to cm_id_priv->av.port being initialized. Should an error be returned for this case ?
Can you reference the place in the code where you think that this could happen? The port should be set before a REQ is sent or immediately after one is received.
The simplest case is the cm id is created and then ib_send_cm_dreq is called. There may be others. Is this worth protecting against ?
Hmm... I'm not sure if it's worth protecting against that in the kernel. But this occurs in most of the APIs.
I allocated the message before checking the state to avoid doing the message allocation and formatting while holding the spinlock, and to avoid complicated error recovery if the allocation failed. For example, changing the state first, then performing the allocation outside of the spinlock can lead to situations where the state can change as a result of receiving an incoming message. So, if the allocation fails, it's difficult to determine what needs to be done.
The drawback is that if the user calls the API at random, then you're correct, the av.port field may not be initialized and would crash the system. I need to think about whether a reasonable app could hit this condition though, and whether a simple not NULL check in cm_alloc_msg is sufficient protection.
- 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
