[openib-general] Re: uCM create connection ID

[Libor Michalek]

On Wed, Jun 29, 2005 at 11:16:19AM -0700, Sean Hefty wrote:
> Libor Michalek wrote:
> >>Is it possible for a consumer of uCM to provide a context with the 
> >>create_id that could be returned with the event? I will have some scale 
> >>up issues if I have to walk a list looking for a uCM provided connection 
> >>ID instead of a context that could point directly to the appropriate 
> >>uDAPL CM object.
> > 
> >   It would be easy to add in a context variable. I had left it out on
> > purpose, since it's easy to get into a situation where using the context
> > as a pointer you can end up referencing deallocated memory. However, I
> > suppose it should be there for flexability.
> 
> Can you explain the situation where the application could reference 
> deallocated memory?  I would think that the uCM could take steps that would 
> make it impossible for a well written app from doing this.

  Assume that the userspace 'struct ib_cm_event' contains the cm_id as
well as a new 'u64 context' which is inherited from the cm_id, and is
set at the time of the cm_id creation. This is what I'm assuming that
Arlin would like to see.

  In the case of two threads accessing the CM at once there's a race
condition if you are going to use the 'context' variable as a pointer
to memory:

Thread 1                              Thread 2
------------------------------------- -----------------------------------
cm_object = malloc(sizeof(*cm_object)
ib_cm_create_id(&cm_object->cm_id,
                (u64)cm_object)

                                      ib_cm_event_get(&event)
ib_cm_destroy_id(cm_object->cm_id)
free(cm_object);
                                      process_event((void *)event->context);


  If you're going to insist on using threads, the context variable
should provide a reference into some table which contains the cm_object
and that table (e.g. lookup, add, remove) needs to be sync'd with a 
thread lock.


-Libor