[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