[openib-general] cm_copy_private_data() : BUG or feature ?

[Sean Hefty]

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