|SUCCESS| net/af_xdp: fix resource leak in eth_dev_close

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

git sha: FEA1D5B98F367DFC+20260407021428.620-1-ouyanghao at tencent.com
Author: Ouyang Hao <ouyanghao at tencent.com>
Subject: [PATCH] net/af_xdp: fix resource leak in eth_dev_close

The patch addresses a memory management issue in the AF_XDP driver where
individual queue elements were being freed incorrectly, causing resource
leaks and potential use-after-free conditions.

> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index 10dbcf1333..2cdb533276 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -1069,12 +1069,10 @@ eth_dev_close(struct rte_eth_dev *dev)
>  		if (rte_atomic_fetch_sub_explicit(&rxq->umem->refcnt, 1,
>  				rte_memory_order_acquire) - 1 == 0)
>  			xdp_umem_destroy(rxq->umem);
> -
> -		/* free pkt_tx_queue */
> -		rte_free(rxq->pair);
> -		rte_free(rxq);
>  	}
> -
> +	/* Free Tx and Rx queue arrays */
> +	rte_free(internals->tx_queues);
> +	rte_free(internals->rx_queues);

Does this code skip freeing resources allocated per-queue? The original
code calls rte_free(rxq->pair) for each queue. If rxq->pair points to
per-queue allocated memory (not part of the rx_queues array), does the
new code leak all the pair structures?

Looking at the loop structure, it iterates through rx_queues but only
decrements umem reference counts. If rxq->pair is separately allocated
(e.g., in eth_rx_queue_setup()), then removing rte_free(rxq->pair)
creates a memory leak for every configured queue's pair structure.

Can you verify whether rxq->pair points to memory within the tx_queues
array allocation, or if it's separately allocated per queue? If it's
separately allocated, the rte_free(rxq->pair) calls need to be retained.

Also, does the loop still correctly handle the case where some queues
may not be configured? If internals->rx_queues[i] is NULL or
rxq->umem is NULL for unconfigured queues, will the array freeing logic
at the end still work correctly?