[openib-general] qp lock in mthca_poll_cq

[Roland Dreier]

    Michael> Wouldnt locking the cq while QP is being destroyed also
    Michael> work?  And maybe the eq which gets the async events.

Yes, that's a good idea, trading some locking in the slow destroy path
for removing an atomic access in the data path.  EQ access is
currently lock-free, but replacing the atomic_t refcounting of
individual resources with a per-EQ spinlock should if anything be a
little more cache friendly.  I'll add this to my TODO list (I need to
take care that the locking hierarchies are OK to avoid deadlocks).

    Michael> It says there: * We have one global lock that protects
    Michael> dev->cq/qp_table.  Each * struct mthca_cq/qp also has its
    Michael> own lock.  No locks should be * nested inside each other.

    Michael> However mthca_poll_one takes qp->lock while cq->lock is
    Michael> being held in mthca_poll_cq.  Isn't that nesting?

Yes, as usual the comment has not kept up with the code.  I'll update this.
(There's no risk of deadlock with that nesting)

 - Roland