|SUCCESS| [1/1] net/mlx5: fix crash if malloc FCQS fails

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163288

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-24

commit a1b2c3d4e5f6
Author: Yunjian Wang <wangyunjian at huawei.com>
Subject: net/mlx5: fix crash if malloc FCQS fails

The patch addresses a crash that occurs when memory allocation for FCQS
fails during TX queue startup. The issue arises because the error path
attempts to remove txq_ctrl->obj from a linked list before it has been
added to the list, resulting in a null pointer dereference.

> diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
> index a070aaecfd..594b518ba6 100644
> --- a/drivers/net/mlx5/mlx5_trigger.c
> +++ b/drivers/net/mlx5/mlx5_trigger.c
> @@ -97,6 +97,9 @@ mlx5_txq_start(struct rte_eth_dev *dev)
>  					DRV_LOG(ERR, "Port %u Tx queue %u cannot "
>  						"allocate memory (FCQ).",
>  						dev->data->port_id, i);
> +					priv->obj_ops.txq_obj_release(txq_ctrl->obj);
> +					mlx5_free(txq_ctrl->obj);
> +					txq_ctrl->obj = NULL;
>  					rte_errno = ENOMEM;
>  					goto error;
>  				}

Does this code introduce a double-free issue? Looking at the error
handling path, the 'goto error' statement leads to cleanup code that
likely calls mlx5_txq_release() (as indicated by the stack trace). If
mlx5_txq_release() also attempts to free txq_ctrl->obj after this patch
manually frees it, would that cause a double-free?

Additionally, does priv->obj_ops.txq_obj_release() expect txq_ctrl->obj
to be non-NULL and fully initialized? If the FCQS allocation failure
occurs early in the object initialization, could calling txq_obj_release()
on a partially initialized object lead to issues?

Would it be safer to track the initialization state of txq_ctrl->obj and
only perform cleanup operations that match what has actually been
initialized at the point of failure?