| Message ID | 1646315417-25549-1-git-send-email-haakon.bugge@oracle.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Leon Romanovsky |
| Headers | show |
| Series | [for-next] Revert "IB/mlx5: Don't return errors from poll_cq" | expand |
On Thu, Mar 03, 2022 at 02:50:17PM +0100, Håkon Bugge wrote: > This reverts commit dbdf7d4e7f911f79ceb08365a756bbf6eecac81c. > > Commit dbdf7d4e7f91 ("IB/mlx5: Don't return errors from poll_cq") is > needed, when driver/fw communication gets wedged. > > With a large fleet of systems equipped with CX-5, we have observed the > following mlx5 error message: > > wait_func:945:(pid xxx): ACCESS_REG(0x805) timeout. Will cause a > leak of a command resource It is arguably FW issue. Please contact your Nvidia support representative. Thanks
> On 3 Mar 2022, at 20:09, Leon Romanovsky <leon@kernel.org> wrote: > > On Thu, Mar 03, 2022 at 02:50:17PM +0100, Håkon Bugge wrote: >> This reverts commit dbdf7d4e7f911f79ceb08365a756bbf6eecac81c. >> >> Commit dbdf7d4e7f91 ("IB/mlx5: Don't return errors from poll_cq") is >> needed, when driver/fw communication gets wedged. >> >> With a large fleet of systems equipped with CX-5, we have observed the >> following mlx5 error message: >> >> wait_func:945:(pid xxx): ACCESS_REG(0x805) timeout. Will cause a >> leak of a command resource > > It is arguably FW issue. Please contact your Nvidia support representative. The RC for the whacked driver/fw communication has been raised with Nvidia support. This commit is to avoid the kernel to crash when this situation arises. And inevitable, it may happen. Thxs, Håkon
On Fri, Mar 04, 2022 at 10:53:34AM +0000, Haakon Bugge wrote: > > > > On 3 Mar 2022, at 20:09, Leon Romanovsky <leon@kernel.org> wrote: > > > > On Thu, Mar 03, 2022 at 02:50:17PM +0100, Håkon Bugge wrote: > >> This reverts commit dbdf7d4e7f911f79ceb08365a756bbf6eecac81c. > >> > >> Commit dbdf7d4e7f91 ("IB/mlx5: Don't return errors from poll_cq") is > >> needed, when driver/fw communication gets wedged. > >> > >> With a large fleet of systems equipped with CX-5, we have observed the > >> following mlx5 error message: > >> > >> wait_func:945:(pid xxx): ACCESS_REG(0x805) timeout. Will cause a > >> leak of a command resource > > > > It is arguably FW issue. Please contact your Nvidia support representative. > > The RC for the whacked driver/fw communication has been raised with Nvidia support. This commit is to avoid the kernel to crash when this situation arises. And inevitable, it may happen. I'm confident that support team will find best possible solution to the raised issue. Thanks > > > Thxs, Håkon
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c index 08371a8..2bb9aa0 100644 --- a/drivers/infiniband/hw/mlx5/cq.c +++ b/drivers/infiniband/hw/mlx5/cq.c @@ -490,6 +490,12 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq, * from the table. */ mqp = radix_tree_lookup(&dev->qp_table.tree, qpn); + if (unlikely(!mqp)) { + mlx5_ib_warn(dev, "CQE@CQ %06x for unknown QPN %6x\n", + cq->mcq.cqn, qpn); + return -EINVAL; + } + *cur_qp = to_mibqp(mqp); } @@ -552,6 +558,13 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq, xa_lock(&dev->sig_mrs); sig = xa_load(&dev->sig_mrs, mlx5_base_mkey(be32_to_cpu(sig_err_cqe->mkey))); + if (unlikely(!sig)) { + xa_unlock(&dev->sig_mrs); + mlx5_ib_warn(dev, "Unable to retrieve sig_mr for mkey %6x\n", + be32_to_cpu(sig_err_cqe->mkey)); + return -EINVAL; + } + get_sig_err_item(sig_err_cqe, &sig->err_item); sig->sig_err_exists = true; sig->sigerr_count++; @@ -606,6 +619,7 @@ int mlx5_ib_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc *wc) unsigned long flags; int soft_polled = 0; int npolled; + int err = 0; spin_lock_irqsave(&cq->lock, flags); if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) { @@ -622,7 +636,8 @@ int mlx5_ib_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc *wc) soft_polled = poll_soft_wc(cq, num_entries, wc, false); for (npolled = 0; npolled < num_entries - soft_polled; npolled++) { - if (mlx5_poll_one(cq, &cur_qp, wc + soft_polled + npolled)) + err = mlx5_poll_one(cq, &cur_qp, wc + soft_polled + npolled); + if (err) break; } @@ -631,7 +646,10 @@ int mlx5_ib_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc *wc) out: spin_unlock_irqrestore(&cq->lock, flags); - return soft_polled + npolled; + if (err == 0 || err == -EAGAIN) + return soft_polled + npolled; + else + return err; } int mlx5_ib_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify_flags flags)
This reverts commit dbdf7d4e7f911f79ceb08365a756bbf6eecac81c. Commit dbdf7d4e7f91 ("IB/mlx5: Don't return errors from poll_cq") is needed, when driver/fw communication gets wedged. With a large fleet of systems equipped with CX-5, we have observed the following mlx5 error message: wait_func:945:(pid xxx): ACCESS_REG(0x805) timeout. Will cause a leak of a command resource Followed by: destroy_qp_common:2109:(pid xxx): mlx5_ib: modify QP 0x007264 to RESET failed However, the QP is removed from the device drivers perspective, in particular, the QP number is removed from the radix tree. We may further assume that the HCA has not been informed about the intent of destroying the QP and setting its state to RESET. We may then poll CQEs from the HCA for this QP. Then we may end up in mlx5_poll_one() doing: mqp = radix_tree_lookup(&dev->qp_table.tree, qpn); *cur_qp = to_mibqp(mqp); which, in the event no QP is found, leads to the following NULL pointer deref: BUG: unable to handle kernel paging request at fffffffffffffff8 IP: mlx5_poll_one+0xd0/0xbb0 [mlx5_ib] Note that the above is based on a 4.14.35 kernel, but my take is that this analysis is also applicable to latest upstream. Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Conflicts: drivers/infiniband/hw/mlx5/cq.c --- drivers/infiniband/hw/mlx5/cq.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)