Re: [net-next,v23,5/6] eea: introduce ethtool support

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
---
eea: introduce ethtool support

This commit adds ethtool support for the Alibaba Elastic Ethernet Adapter
(EEA) driver, including statistics retrieval, ring parameter configuration,
and channel management.

[ ... ]

+static void eea_get_ethtool_stats(struct net_device *netdev,
+				  struct ethtool_stats *stats, u64 *data)
+{
+	struct eea_net *enet = netdev_priv(netdev);
+	u32 i, idx = 0;
+
+	for (i = 0; i < enet->cfg.rx_ring_num; i++) {
+		struct eea_net_rx *rx = enet->rx[i];

Can this dereference of enet->rx[i] cause a NULL pointer crash when the
device is not running?

Looking at the driver lifecycle, enet->rx is NULL after probe (before the
device is opened) and after close. However, enet->cfg.rx_ring_num is set
to a non-zero value during probe via eea_update_cfg(). This means if a
user runs "ethtool -S ethX" on a device that has not been brought up,
the loop will execute with enet->rx being NULL.

The follow-up commit 3b731fea0a60 ("eea: introduce callback for
ndo_get_stats64") adds an "if (enet->rx)" check before a similar loop in
eea_stats(), suggesting awareness of this issue. Should a similar check
be added here?

+
+		eea_stats_fill_for_q(&rx->stats.syncp, EEA_RX_STATS_LEN,
+				     eea_rx_stats_desc, data, idx);
+
+		idx += EEA_RX_STATS_LEN;
+	}
+
+	for (i = 0; i < enet->cfg.tx_ring_num; i++) {
+		struct eea_net_tx *tx = &enet->tx[i];

The same question applies here for enet->tx.

+
+		eea_stats_fill_for_q(&tx->stats.syncp, EEA_TX_STATS_LEN,
+				     eea_tx_stats_desc, data, idx);
+
+		idx += EEA_TX_STATS_LEN;
+	}
+}

[ ... ]