2026/2/26 17:58, "Sebastian Andrzej Siewior" <bigeasy@linutronix.de mailto:bigeasy@linutronix.de?to=%22Sebastian%20Andrzej%20Siewior%22%20%3Cbigeasy%40linutronix.de%3E > wrote:

On 2026-02-24 19:25:41 [+0800], Jiayuan Chen wrote:

quoted

--- a/net/core/filter.c
 +++ b/net/core/filter.c
 @@ -4387,6 +4387,9 @@ u32 xdp_master_redirect(struct xdp_buff *xdp)
 struct net_device *master, *slave;
 
 master = netdev_master_upper_dev_get_rcu(xdp->rxq->dev);
 + if (unlikely(!master || !netif_running(master)))
 + return XDP_TX;
 +

I'm not sure this check belongs here as this is not bond specific, is
it? Also nothing stops the admin to put the device right after the
netif_running() check so it fails later but the race window is not as
wide as it is now.

The per-CPU memory could be allocated while the bond device is created.
I don't think delaying it until "device up" brings any advantages.
One creates the device with the intention to use it so the "up" is
inevitable.
The bond_xmit_get_slave() callback has the same logic. Couldn't this
scenario also occur to the ->ndo_get_xmit_slave() user?

quoted

slave = master->netdev_ops->ndo_xdp_get_xmit_slave(master, xdp);
 if (slave && slave != xdp->rxq->dev) {
 /* The target device is different from the receiving device, so

Sebastian

I agree with your points, especially allocating
rr_tx_counter unconditionally at device creation time in bond_setup().

This eliminates the NULL possibility from the root, fixes both the
ndo_xdp_get_xmit_slave and ndo_get_xmit_slave paths, and keeps the
change within the bonding subsystem.

I'll wait a bit to collect more feedback before sending a v2.