On Fri, Jan 20, 2012 at 8:14 AM, Bernd Schubert <[email protected]> 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? > > > However, what is is with user space setting type to IB_QPT_XRC_TGT? I guess > this could be solved by letting the kernel zero the memory returned by > ->ops.create_qp(pd, qp_init_attr). > Btw, I didn't figure out yet, how this translates at all in kernel space? Is > this op directly going to the device driver? > > But even if we are properly going to initialize the qp, what is with user > space mischievously trying to crash the system by manipulating struct ib_qp > *qp? I don't follow this. Isn't *qp completely allocated and manipulated in the kernel? How can userspace touch it except by having the kernel do something via the uverbs interface? - R. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
