2022-03-03 16:32:16

by Håkon Bugge

[permalink] [raw]
Subject: [PATCH for-next] Revert "IB/mlx5: Don't return errors from poll_cq"

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 <[email protected]>

Conflicts:
drivers/infiniband/hw/mlx5/cq.c
---
drivers/infiniband/hw/mlx5/cq.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)

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)
--
1.8.3.1


2022-03-03 19:48:46

by Leon Romanovsky

[permalink] [raw]
Subject: Re: [PATCH for-next] Revert "IB/mlx5: Don't return errors from poll_cq"

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

2022-03-04 14:38:13

by Håkon Bugge

[permalink] [raw]
Subject: Re: [PATCH for-next] Revert "IB/mlx5: Don't return errors from poll_cq"



> On 3 Mar 2022, at 20:09, Leon Romanovsky <[email protected]> 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

2022-03-04 18:06:23

by Leon Romanovsky

[permalink] [raw]
Subject: Re: [PATCH for-next] Revert "IB/mlx5: Don't return errors from poll_cq"

On Fri, Mar 04, 2022 at 10:53:34AM +0000, Haakon Bugge wrote:
>
>
> > On 3 Mar 2022, at 20:09, Leon Romanovsky <[email protected]> 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