[ofw] [PATCH 3/7] ib/cm: export CM only interface

[Sean Hefty]

>> I'm guessing that an IBAL userspace application doesn't have any way
>> of destroying a connection separate from destroying the QP.
>
>It can disconnect the QP without destroying it.  Destroying a connected QP
>however implicitly disconnects it.

I should have been clearer.  The app can only use the QP to destroy the kernel
CEP.  If the QP's CID is wrong, there's no other way for the app to destroy the
CEP.  (I'm assuming this is the case.)

Trying to trace through QP destruction, I think this is the code path that's
followed:

invokes qp->pfn_destroy()
maps to async_destroy_obj()
calls destroy_obj()
this changes the QP state:
	lock
	state = destroying
	unlock
also calls qp->pfn_destroying
maps to destroying_qp()
calls al_destroy_cep()

Finally everything unwinds, and the user's destroy callback is invoked after the
reference count drops to zero.

Note that no lock is held between setting the QP state to destroying and calling
al_destroy_cep().  This means that another thread can reference the QP before it
is in the destroying state, the destroy thread can execute, then the QP's CID
can be set.  I think the synchronization that I mentioned in my previous mail
handles this, and I'm not seeing a simpler solution at this point.  (I.e. Fixing
just al_destroy_cep won't work.)

I'm going to add that change to my patch and see if it works.

- Sean