On Thu, 26 Mar 2026 13:46:11 +0100
David Marchand <[email protected]> wrote:
> In case no rxq has been set up (like when starting testpmd with no mempool
> drivers), a crash happens in tap_dev_close:
>
> Thread 1 "dpdk-testpmd" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7fad68b in tap_dev_close (dev=dev@entry=0x4c4a80
> <rte_eth_devices@INTERNAL>) at ../drivers/net/tap/rte_eth_tap.c:1111
> 1111 struct rx_queue *rxq = dev->data->rx_queues[i];
>
> (gdb) p dev->data->rx_queues
> $4 = (void **) 0x0
>
> Fixes: 23e2387b49a1 ("net/tap: allocate queue structures dynamically")
>
> Signed-off-by: David Marchand <[email protected]>
> ---
It looked ok, but then the AI review spotted some stuff...
Two issues:
The txq variable is declared as struct rx_queue * but should be
struct tx_queue *. Works by accident since it comes from a void *
array and is only NULL-tested and passed to rte_free(), but the
type is wrong.
Pre-existing: the loop runs to RTE_PMD_TAP_MAX_QUEUES but the
rx_queues/tx_queues arrays are allocated with nb_rx_queues /
nb_tx_queues entries by ethdev. If dev_configure() was called
with fewer queues, the arrays are non-NULL but the access is
out-of-bounds. Since these lines are being reworked anyway, worth
adding a bounds check against nb_rx_queues/nb_tx_queues. The
tap_queue_close() call is fine -- process_private fds are sized
to RTE_PMD_TAP_MAX_QUEUES.
Also missing Cc: [email protected] for a crash fix.