> > Yes, but it ends up calling __ib_process_cq() which doesn't actually poll
> the CQ because cq->wc is NULL.
>
> Do you mean that the CQ allocation wasn't done with ib_alloc_cq? That
> indeed would be a bug. We can WARN on it as well so the application
> will know to allocate its CQ with ib_alloc_cq.
Yes, the application used ib_create_cq().
>
> Does something like this makes sense?
>
That would at least log the issue, but the thread in ib_drain_qp() will be stuck forever continually blocking for 1/10sec and then polling. Perhaps the drain logic should detect this, and then return?
Is there a reason we don't get rid of ib_create_cq()? Or just make it call ib_alloc_cq()...
> --
> diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
> index f2ae75fa3128..90eac56b5f1a 100644
> --- a/drivers/infiniband/core/cq.c
> +++ b/drivers/infiniband/core/cq.c
> @@ -69,7 +69,7 @@ static int __ib_process_cq(struct ib_cq *cq, int budget)
> */
> int ib_process_cq_direct(struct ib_cq *cq, int budget)
> {
> - WARN_ON_ONCE(cq->poll_ctx != IB_POLL_DIRECT);
> + WARN_ON_ONCE(cq->poll_ctx != IB_POLL_DIRECT || !cq->wc);
>
> return __ib_process_cq(cq, budget);
> }
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
