[openib-general] Re: race in mthca_cq.c?

[Roland Dreier]

 > 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.