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

Sean Hefty sean.hefty at intel.com
Thu Jan 22 10:04:11 PST 2009


>* Allows a user to connect or accept on an already connected QP.  Beyond the
>user breaking their own communication, what actual harm does this cause?  Does
>this leak CEPs?  I removed this check
>
>* Does not allow a user to connect or accept on a QP while trying to destroy
>it,
>or it leaks CEPs.  Apparently the kernel proxy code, including the ND changes,
>can behave this way.
>
>Are leaked CEPs cleaned up when the application exits?

As far as I can tell the two issues mentioned above are the problems.  A dumb
application can leak CEPs until it exits.  I believe that the latter problem
exists even without this patch.

I think it would be clear what races were being protected against if the two
IOCTL handling areas of IBAL were structured as:

lock(qp);
if (qp->state == destroying || qp->cid != invalid) {
	unlock(qp);
	fail;
}

...
qp->cid = new cid;
unlock(qp);

I'm guessing that an IBAL userspace application doesn't have any way of
destroying a connection separate from destroying the QP.

- Sean




More information about the ofw mailing list