Hi,

Roland Dreier wrote on 01/20/2012 07:43 PM:
On Fri, Jan 20, 2012 at 10:40 AM, Roland Dreier<rol...@purestorage.com>  wrote:
On Fri, Jan 20, 2012 at 8:14 AM, Bernd Schubert
<bernd.schub...@itwm.fraunhofer.de>  wrote:
I *guess* the qp allocated by pd->context->ops.create_qp() does not have
qp->usecnt initialized (not does it know anything about it). So its random
value will fail the destruction later. A simple workaround that would work
for us, is to extend the patch I send to

diff --git a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
index 602b1bd..fba1675 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -874,7 +874,7 @@ int ib_destroy_qp(struct ib_qp *qp)
        struct ib_srq *srq;
        int ret;

-       if (atomic_read(&qp->usecnt))
+       if (qp->qp_type == IB_QPT_XRC_TGT&&  atomic_read(&qp->usecnt))
                return -EBUSY;

        if (qp->real_qp != qp)

It looks like this is sufficient and correct without the other patch?

But maybe it's cleaner to initialize qp->usecnt in
both ib_create_qp() and ib_uverbs_create_qp().

  - R.


is there any progress on this? We have already reached Linux stable 3.2.2 and IB still appears to be broken (at least for mthca) because of this.

Best regards,
Sven

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to