From: Raslan Darawsheh <rasland@nvidia.com>
To: Maayan Kashani <mkashani@nvidia.com>, dev@dpdk.org
Cc: 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>
Subject: Re: [PATCH] net/mlx5: fix state corruption in dev start error path
Date: Mon, 17 Nov 2025 16:01:09 +0200 [thread overview]
Message-ID: <35424992-4e2a-4b3f-94a9-b8838b116b45@nvidia.com> (raw)
In-Reply-To: <20251113193711.7883-1-mkashani@nvidia.com>
Hi,
On 13/11/2025 9:37 PM, Maayan Kashani wrote:
> When mlx5_dev_start() fails partway through initialization, the error
> cleanup code unconditionally calls cleanup functions for all steps,
> including those that were never successfully initialized. This causes
> state corruption leading to incorrect behavior on subsequent start
> attempts.
>
> The issue manifests as:
> 1. First start attempt fails with -ENOMEM (expected)
> 2. Second start attempt returns -EINVAL instead of -ENOMEM
> 3. With flow isolated mode, second attempt incorrectly succeeds,
> leading to segfault in rte_eth_rx_burst()
>
> Root cause: The single error label cleanup path calls functions like
> mlx5_traffic_disable() and mlx5_flow_stop_default() even when their
> corresponding initialization functions (mlx5_traffic_enable() and
> mlx5_flow_start_default()) were never called due to earlier failure.
>
> For example, when mlx5_rxq_start() fails:
> - mlx5_traffic_enable() at line 1403 never executes
> - mlx5_flow_start_default() at line 1420 never executes
> - But cleanup unconditionally calls:
> * mlx5_traffic_disable() - destroys control flows list
> * mlx5_flow_stop_default() - corrupts flow metadata state
>
> This corrupts the device state, causing subsequent start attempts to
> fail with different errors or, in isolated mode, to incorrectly succeed
> with an improperly initialized device.
>
> Fix by replacing the single error label with cascading error labels
> (Linux kernel style). Each label cleans up only its corresponding step,
> then falls through to clean up earlier steps.
> This ensures only successfully initialized steps are cleaned up,
> maintaining device state consistency across failed start attempts.
>
> Bugzilla ID: 1419
> Fixes: 8db7e3b69822 ("net/mlx5: change operations for non-cached flows")
> Cc: stable@dpdk.org
>
> Signed-off-by: Maayan Kashani <mkashani@nvidia.com>
> Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> ---
Patch applied to next-net-mlx,
Kindest regards
Raslan Darawsheh
prev parent reply other threads:[~2025-11-17 14:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 19:37 Maayan Kashani
2025-11-17 14:01 ` Raslan Darawsheh [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=35424992-4e2a-4b3f-94a9-b8838b116b45@nvidia.com \
--to=rasland@nvidia.com \
--cc=bingz@nvidia.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=matan@nvidia.com \
--cc=mkashani@nvidia.com \
--cc=orika@nvidia.com \
--cc=stable@dpdk.org \
--cc=suanmingm@nvidia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).