Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next] RDMA/bnxt_re: Limit SRQ depth to the firmware command field
Date: Tue, 15 Sep 2026 21:46:15 +0300	[thread overview]
Message-ID: <20260915184615.GQ13683@unreal> (raw)
In-Reply-To: <20260915132428.2C67B1F0089B@smtp.kernel.org>

On Tue, Sep 15, 2026 at 01:24:27PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] RDMA/bnxt_re: silent SRQ desync for legacy userspace due to non-power-of-two cap
> --
> 
> commit a0fff360dfd527e4f635aa0d8696bce687733ce9
> Author: Leon Romanovsky <leon@kernel.org>
> 
> RDMA/bnxt_re: Limit SRQ depth to the firmware command field
> 
> Firmware can report an SRQ depth above 16 bits, but CREATE_SRQ carries the
> allocated depth in a 16-bit field. Requests near the advertised limit can
> therefore truncate the command value and make firmware use a different
> depth than the allocated queue.
> 
> > diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > index ef08d42f377e6..43ff3e7a459fa 100644
> > --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > @@ -2229,8 +2229,8 @@ int bnxt_re_create_srq(struct ib_srq *ib_srq,
> >  	dev_attr = rdev->dev_attr;
> >  	srq = container_of(ib_srq, struct bnxt_re_srq, ib_srq);
> >  
> > -	if (srq_init_attr->attr.max_wr >= dev_attr->max_srq_wqes) {
> > -		ibdev_err(&rdev->ibdev, "Create CQ failed - max exceeded");
> > +	if (srq_init_attr->attr.max_wr > dev_attr->max_srq_wqes) {
> > +		ibdev_err(&rdev->ibdev, "Create SRQ failed - max exceeded");
> >  		rc = -EINVAL;
> >  		goto exit;
> >  	}
> > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > index ec9eb52a8ebf7..63dcbb9d80f4b 100644
> > --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > @@ -159,7 +159,8 @@ int bnxt_qplib_get_dev_attr(struct bnxt_qplib_rcfw *rcfw)
> >  	attr->max_ah = le32_to_cpu(sb->max_ah);
> >  
> >  	attr->max_srq = le16_to_cpu(sb->max_srq);
> > -	attr->max_srq_wqes = le32_to_cpu(sb->max_srq_wr) - 1;
> > +	attr->max_srq_wqes = min_t(u32, le32_to_cpu(sb->max_srq_wr),
> > +				   U16_MAX) - 1;
> 
> [Severity: High]
> Does capping max_srq_wqes to 65534 break legacy userspace applications that
> rely on power-of-two queue sizes?

Sashiko has a point, the power-of-two is negotiated with
BNXT_RE_UCNTX_CMASK_POW2_DISABLED bit.

Thanks

> 
> If a legacy application requests an SRQ size that rounds up to 65536
> (e.g. 32768), bnxt_re_create_srq() will pass dev_attr->max_srq_wqes + 1
> (65535) as the maximum to bnxt_re_init_depth():
> 
> drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_create_srq() {
>     ...
> 	srq->qplib_srq.max_wqe =
> 		bnxt_re_init_depth(srq_init_attr->attr.max_wr + 1,
> 				   dev_attr->max_srq_wqes + 1, uctx);
>     ...
> }
> 
> In bnxt_re_init_depth(), this results in min(65536, 65535) and returns 65535:
> 
> drivers/infiniband/hw/bnxt_re/ib_verbs.h:bnxt_re_init_depth() {
>     ...
> 	if (uctx && !(uctx->cmask & BNXT_RE_UCNTX_CAP_POW2_DISABLED))
> 		return min(roundup_pow_of_two(ent), max);
>     ...
> }
> 
> Because 65535 is not a power of two, legacy userspace masking (e.g., idx &
> 0xFFFE) becomes mathematically incorrect, immediately corrupting ring state
> and causing producer/consumer desynchronization without throwing an error.
> 
> >  	attr->max_srq_sges = sb->max_srq_sge;
> >  	attr->max_pkey = 1;
> >  	attr->max_inline_data = attr->max_qp_sges * sizeof(struct sq_sge);
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260915-silent-16-bit-truncation-of-srq-size-v1-1-3199f8fe94bc@nvidia.com?part=1

  reply	other threads:[~2026-09-15 18:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 13:09 [PATCH rdma-next] RDMA/bnxt_re: Limit SRQ depth to the firmware command field Leon Romanovsky
2026-09-15 13:24 ` sashiko-bot
2026-09-15 18:46   ` Leon Romanovsky [this message]
2026-09-16  8:06     ` Kalesh Anakkur Purayil
2026-09-16  8:16       ` Leon Romanovsky

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=20260915184615.GQ13683@unreal \
    --to=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox