2026/2/26 17:58, "Sebastian Andrzej Siewior" <[email protected]
mailto:[email protected]?to=%22Sebastian%20Andrzej%20Siewior%22%20%3Cbigeasy%40linutronix.de%3E
> wrote:
>
> On 2026-02-24 19:25:41 [+0800], Jiayuan Chen wrote:
>
> >
> > --- 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?
>
> >
> > 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.
