[openib-general] Re: race in mthca_cq.c?
Michael S. Tsirkin
mst at mellanox.co.il
Thu Jun 8 13:48:26 PDT 2006
Quoting r. Roland Dreier <rdreier at cisco.com>:
> 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
More information about the general
mailing list