From: sys_stv@intel.com
To: test-report@dpdk.org
Cc: mkashani@nvidia.com
Subject: |SUCCESS|dpdk-next-net-mlx|29172eaff0| intel-Functional
Date: 18 Nov 2025 04:34:50 -0800 [thread overview]
Message-ID: <7b7dee$5lmubi@orviesa009-auth.jf.intel.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5435 bytes --]
Test-Label: intel-Functional
Test-Status: SUCCESS
_Functional PASS_
DPDK git repo: dpdk-next-net-mlx
commit 29172eaff04e864c11ebcc1cf2771c38099ee42f
Author: Maayan Kashani <mkashani@nvidia.com>
Date: Thu Nov 13 21:37:11 2025 +0200
net/mlx5: fix state corruption in dev start error path
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>
Smoke-Testing Summary : 31 Case Done, 31 Successful, 0 Failures
OS : Ubuntu 24.04.3 LTS
Kernel : 6.8.0-71-generic
GCC : 13.3.0-6ubuntu2~24.04
NIC : Ethernet Controller XL710 for 40GbE QSFP+
Target : x86_64-native-linuxapp-gcc
Test result details:
+-----------------+---------------------------------------------------+-------+
| suite | case | status|
+-----------------+---------------------------------------------------+-------+
| checksum_offload| test_checksum_offload_with_vlan | passed|
| checksum_offload| test_do_not_insert_checksum_on_the_transmit_packet| passed|
| checksum_offload| test_hardware_checksum_check_ip_rx | passed|
| checksum_offload| test_hardware_checksum_check_ip_tx | passed|
| checksum_offload| test_hardware_checksum_check_l4_rx | passed|
| checksum_offload| test_insert_checksum_on_the_transmit_packet | passed|
| checksum_offload| test_rx_checksum_valid_flags | passed|
| checksum_offload| test_hardware_checksum_check_l4_tx | n/a |
| dual_vlan | test_dual_vlan_priority_rxtx | passed|
| dual_vlan | test_vlan_filter_config | passed|
| dual_vlan | test_vlan_filter_table | passed|
| dual_vlan | test_vlan_insert_config | passed|
| dual_vlan | test_vlan_random_test | passed|
| dual_vlan | test_vlan_strip_config | passed|
| dual_vlan | test_vlan_synthetic_test | passed|
| dual_vlan | test_vlan_tpid_config | passed|
| dual_vlan | test_vlan_stripq_config | n/a |
| jumboframes | test_jumboframes_bigger_jumbo | passed|
| jumboframes | test_jumboframes_jumbo_jumbo | passed|
| jumboframes | test_jumboframes_jumbo_nojumbo | passed|
| jumboframes | test_jumboframes_normal_jumbo | passed|
| jumboframes | test_jumboframes_normal_nojumbo | passed|
| rxtx_offload | test_rxoffload_port_all | passed|
| rxtx_offload | test_rxoffload_port_cmdline | passed|
| rxtx_offload | test_txoffload_port | passed|
| rxtx_offload | test_txoffload_port_all | passed|
| rxtx_offload | test_txoffload_port_checksum | passed|
| rxtx_offload | test_txoffload_port_cmdline | passed|
| rxtx_offload | test_txoffload_port_multi_segs | passed|
| rxtx_offload | test_txoffload_queue | passed|
| rxtx_offload | test_rxoffload_queue | n/a |
+-----------------+---------------------------------------------------+-------+
DPDK STV team
reply other threads:[~2025-11-18 12:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='7b7dee$5lmubi@orviesa009-auth.jf.intel.com' \
--to=sys_stv@intel.com \
--cc=mkashani@nvidia.com \
--cc=test-report@dpdk.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 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).