Re: [net-next,v2,4/6] net: bcmgenet: add XDP_TX support

[Nicolai Buchwitz <nb@tipi-net.de>]

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.
> 
>> 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
> 
> [ ... ]
> 
>> @@ -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