> Roland, I think I see a race in mthca: let's assume that > a QP is destroyed. We remove the qpn from qp_table. > > Before we have the chance to cleanup the CQ, another QP is created > and put in the same slot in table. If the user now polls the CQ he'll see a > completion for a wrong QP, since poll CQ does: > > *cur_qp = mthca_array_get(&dev->qp_table.qp, > be32_to_cpu(cqe->my_qpn) & > (dev->limits.num_qps - 1)); > > Is this analysis right?
I don't think so. There's no way for another QP to be assigned the same number, since the mthca_free() to clear out the QPN bitmap doesn't happen until after the CQs are cleaned up. > It seems a similiar issue exists for CQs, does it not? > And I think it can be solved in a similiar way, checking the CQN? I don't see anything there either. When destroying a CQ, mthca does HW2SW_CQ and synchronize_irq() before a new CQ could be created with the same number. - R. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
