Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: race in mthca_cq.c? > > > 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.
Not in the driver I have: mthca_array_clear is at line 1351, mthca_cq_clean at line 1372. Isn't mthca_array_clear freeing the slot in QP table? > > 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. But there might be more EQEs for this CQN outstanding in the EQ which we have not seen yet. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
