Krishna Kumar2 wrote:
Is cm_copy_private_data() intentionally returning NULL rather than, say
something
like, ERR_PTR(-EINVAL) ? The problem is that in the caller, a NULL ptr
translates to
success (0 > unsigned -1000), which might lead to errors in other code
paths.
Though from a cursory examination, I couldn't find any specific oops cases
as
private_data/len seem to be checked, but the problem is that this results
in freeing
up earlier allocated private_data through cm_set_private_data(), while the
id state is
ESTABLISHED. Hence looks like a bug to me.
The code should be correct. The purpose behind the routine is to 'squirrel
away' the user's private data in case it needs to be resent later. If the user
has no private data to send, then the 'copy' is NULL.
The CM must only maintain the private data for the last message sent. For
example, if the user sends an RTU, the CM copies the user's private data in case
the RTU needs to be resent. (In response to a duplicated REP.) If the user
sends a DREQ, the stored private data is replaced with the private data
associated with the DREQ.
The general operation is as follows:
1. Create a copy of the user's private data. This is done outside of holding
any spinlocks, with the assumption that the state machine works as expected.
2. Lock the cm_id.
3. Check the state of the cm_id and transition to the next state.
4. Update the private data for the new state. If there's no new private data to
send, we simply free the old data.
5. Unlock the cm_id.
Hope this helps.
- 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
