From: Stephen Hemminger <stephen@networkplumber.org>
To: Maayan Kashani <mkashani@nvidia.com>
Cc: <dev@dpdk.org>, <rasland@nvidia.com>, <stable@dpdk.org>,
"Dariusz Sosnowski" <dsosnowski@nvidia.com>,
Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
Suanming Mou <suanmingm@nvidia.com>,
Matan Azrad <matan@nvidia.com>,
Thomas Monjalon <thomas@monjalon.net>,
Gregory Etelson <getelson@nvidia.com>
Subject: Re: [PATCH v2] net/mlx5: fix uint16 underflow on Rx queue error path
Date: Mon, 10 Aug 2026 08:24:12 -0700 [thread overview]
Message-ID: <20260810082412.76a25695@phoenix.local> (raw)
In-Reply-To: <20260809094837.123931-1-mkashani@nvidia.com>
On Sun, 9 Aug 2026 12:48:37 +0300
Maayan Kashani <mkashani@nvidia.com> wrote:
> Avoid post-decrementing the segment index when it is zero in the
> error cleanup path of mlx5_rxq_mempool_register().
>
> Coverity issue: 503770
> Fixes: 8d1cb02da5b7 ("net/mlx5: support selective Rx")
> Cc: stable@dpdk.org
>
> Signed-off-by: Maayan Kashani <mkashani@nvidia.com>
> ---
Claude Opus AI review sees dead bodies here...
Review of [PATCH v2] net/mlx5: fix uint16 underflow on Rx queue error path
Warning: undocumented second change, and it is dead code
The commit message describes only the loop restructuring, but the patch
also adds a "seg->mp == NULL" guard around the free:
+ if (seg->mp == NULL) {
+ mlx5_free(seg->null_mbuf);
+ seg->null_mbuf = NULL;
+ }
This guard can never be false for a segment that has a null_mbuf.
seg->null_mbuf is only ever assigned in the mp == NULL branch of the
registration loop (mlx5_trigger.c:179), and rxq_ctrl is allocated with
MLX5_MEM_ZERO (mlx5_rxq.c:1881), so a segment with mp != NULL always has
null_mbuf == NULL. mlx5_free() already returns early on NULL
(drivers/common/mlx5/mlx5_malloc.c:275), so the guard changes nothing.
It also makes this cleanup inconsistent with rxq_free_elts_sprq(),
which frees null_mbuf for every segment unconditionally:
for (i = 0; i < rxq->rxseg_n; i++) {
mlx5_free(rxq->rxseg[i].null_mbuf);
rxq->rxseg[i].null_mbuf = NULL;
}
Suggest dropping the guard so the patch does only what its subject says.
If it is deliberate, say why in the commit message and apply the same
rule in mlx5_rxq.c so the two paths agree.
Info: the underflow has no observable effect
In the original "while (s-- > 0)", s is uint16_t and the comparison uses
the value before the decrement. With s == 0 the body never executes; s
wraps to 0xFFFF but is dead from that point on, so there is no
out-of-bounds index and no misbehaviour. Coverity 503770 is reporting the
wrap of a dead local. The rewrite is behaviour-preserving and fine, but
it would help stable maintainers to state in the commit message that this
is a static-analysis fix with no runtime impact.
Info: no v2 changelog after the "---" separator, so what changed since
20260730135620.213682-1-mkashani@nvidia.com is not visible to reviewers.
prev parent reply other threads:[~2026-08-10 15:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 13:56 [PATCH] net/mlx5: fix uint16 underflow on Rx queue error path Maayan Kashani
2026-08-09 9:48 ` [PATCH v2] " Maayan Kashani
2026-08-10 7:14 ` Bing Zhao
2026-08-10 15:24 ` Stephen Hemminger [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=20260810082412.76a25695@phoenix.local \
--to=stephen@networkplumber.org \
--cc=bingz@nvidia.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=getelson@nvidia.com \
--cc=matan@nvidia.com \
--cc=mkashani@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=stable@dpdk.org \
--cc=suanmingm@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
/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.