From: "Li,Rongqing" <lirongqing@baidu.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: 答复: [????] Re: [PATCH] RDMA/mlx5: Check SIG_ERR CQE mkey lookup before dereferencing
Date: Tue, 29 Sep 2026 01:21:23 +0000 [thread overview]
Message-ID: <eefbecee6ddd474f9d0d50e2eb28ed52@baidu.com> (raw)
In-Reply-To: <20260928183825.GZ563127@unreal>
> On Sat, Sep 19, 2026 at 06:08:06PM +0800, lirongqing wrote:
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > In mlx5_poll_one, a MLX5_CQE_SIG_ERR completion looks up the signature
> > context in dev->sig_mrs via xa_load() but dereferences the result
> > without a NULL check. If the corresponding MR has been concurrently
> > deregistered
>
> Is this real scenario? Integrity MRs are in-kernel MRs, they shouldn't be
> concurrently deregistered.
>
Thanks for the review. You're right ― the concurrent-deregister scenario I described is not reachable in normal use: MLX5_CQE_SIG_ERR is only generated for signature (IB_MR_TYPE_INTEGRITY) MRs, whose mkey is always present in dev->sig_mrs while the operation is in flight, and the null mkey is an ODP-only special case that is never inserted into sig_mrs.
Thanks
[Li,Rongqing]
> Thanks
>
> > (which removes the xarray entry without holding the CQ lock),
> > xa_load() returns NULL and the subsequent
> > get_sig_err_item(sig_err_cqe, &sig->err_item) crashes in atomic context under
> xa_lock.
> >
> > Add a NULL check that drops the lock, logs a warning, and repolls.
> >
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> > drivers/infiniband/hw/mlx5/cq.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/cq.c
> > b/drivers/infiniband/hw/mlx5/cq.c index 49b4bf1..b0b1177 100644
> > --- a/drivers/infiniband/hw/mlx5/cq.c
> > +++ b/drivers/infiniband/hw/mlx5/cq.c
> > @@ -563,6 +563,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 (!sig) {
> > + xa_unlock(&dev->sig_mrs);
> > + mlx5_ib_warn(dev, "CQN: 0x%x Got SIGERR on unknown mkey:
> 0x%x\n",
> > + cq->mcq.cqn,
> > + be32_to_cpu(sig_err_cqe->mkey));
> > + goto repoll;
> > + }
> > get_sig_err_item(sig_err_cqe, &sig->err_item);
> > sig->sig_err_exists = true;
> > sig->sigerr_count++;
> > --
> > 2.9.4
> >
prev parent reply other threads:[~2026-09-29 1:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 10:08 [PATCH] RDMA/mlx5: Check SIG_ERR CQE mkey lookup before dereferencing lirongqing
2026-09-19 10:17 ` sashiko-bot
2026-09-28 18:38 ` Leon Romanovsky
2026-09-29 1:21 ` Li,Rongqing [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eefbecee6ddd474f9d0d50e2eb28ed52@baidu.com \
--to=lirongqing@baidu.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.