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