On 17.3.2026 17:20, Simon Horman wrote:

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see 
https://netdev-ai.bots.linux.dev/ai-local.html
---
net: bcmgenet: add XDP_TX support

Implement XDP_TX using ring 16 (DESC_INDEX), the hardware default
descriptor ring, dedicated to XDP TX for isolation from SKB TX queues.
Ring 16 gets 32 BDs carved from ring 0's allocation. TX completion is
piggybacked on RX NAPI poll since ring 16's INTRL2_1 bit collides with
RX ring 0, similar to how bnxt, ice, and other XDP drivers handle TX
completion within the RX poll path.

quoted

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 

b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f6a2567af7cb..922895bc7461 100644

--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c

[ ... ]

quoted

@@ -3637,6 +3782,7 @@ static void bcmgenet_timeout(struct net_device 

*dev, unsigned int txqueue)

 	for (q = 0; q <= priv->hw_params->tx_queues; q++)
 		bcmgenet_dump_tx_queue(&priv->tx_rings[q]);
+	bcmgenet_dump_tx_queue(&priv->tx_rings[DESC_INDEX]);

Does this trigger an out-of-bounds array access?

Looking at bcmgenet_dump_tx_queue():

static void bcmgenet_dump_tx_queue(struct bcmgenet_tx_ring *ring)
{
	...
	struct netdev_queue *txq = netdev_get_tx_queue(priv->dev, 
ring->index);
	...
}

For the XDP TX ring, ring->index is DESC_INDEX (16), so this calls
netdev_get_tx_queue(priv->dev, 16). But the device only has 5 TX queues
(indices 0-4), allocated via alloc_etherdev_mqs() with 
GENET_MAX_MQ_CNT+1=5.

This means the code accesses dev->_tx[16] which is beyond the allocated
array, and the returned txq pointer points to memory past the array. 
This
is then dereferenced by netif_tx_queue_stopped(txq) which reads 
txq->state
from invalid memory.

In debug builds this triggers DEBUG_NET_WARN_ON_ONCE, and it could 
crash or
corrupt data.

I must have overlooked this, when I was refactoring to ring 16 in v2. 
Will be fixed in v3

Thanks
Nicolai