Re: [PATCH net-next v9 6/7] net: bcmgenet: add XDP statistics counters

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Global XDP statistics are updated concurrently from multiple NAPI contexts without synchronization, leading to data races, lost increments, and rapid overflows.
--

commit 04cdeba59fa183a07b2fd6c8dba32b2dd262ae4d
Author: Nicolai Buchwitz <nb@tipi-net.de>

net: bcmgenet: add XDP statistics counters

Exposes per-action XDP counters via ethtool -S. These counters use the
existing soft MIB infrastructure and are incremented alongside existing
driver statistics in bcmgenet_run_xdp().

> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
[ ... ]
> @@ -2432,6 +2440,7 @@ static unsigned int bcmgenet_run_xdp(struct bcmgenet_rx_ring *ring,
>  
>  	switch (act) {
>  	case XDP_PASS:
> +		priv->mib.xdp_pass++;

Since the driver supports multiple RX queues, bcmgenet_run_xdp() can be
executed concurrently by independent NAPI polling instances on different
CPUs. 

Will these non-atomic read-modify-write operations on the shared priv->mib
structure lead to data races and lost increments?

>  		return XDP_PASS;
>  	case XDP_TX:
[ ... ]
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> @@ -156,6 +156,13 @@ struct bcmgenet_mib_counters {
>  	u32	tx_dma_failed;
>  	u32	tx_realloc_tsb;
>  	u32	tx_realloc_tsb_failed;
> +	u32	xdp_pass;

Because XDP processes packets at high rates, could these 32-bit packet
counters overflow rapidly under heavy traffic?

Would it be safer to maintain these XDP counters as 64-bit values on a
per-queue basis, using u64_stats_t, and aggregate them when queried?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506095553.55357-1-nb@tipi-net.de?part=6