Re: [PATCH net] selftests: bonding: fix failover race in bond_options.sh prio test

[Hangbin Liu <hangbin.liu@linux.dev>]

On Fri, Nov 13, 2026 at 01:23:40PM +0800, Hangbin Liu wrote:
> Hi Pin-yen,
> On Wed, Nov 11, 2026 at 05:46:18PM -0800, Pin-yen Lin wrote:
> > The prio test intermittently fails in the arp_ip_target and
> > ns_ip6_target variants:
> > 
> >   TEST: prio (active-backup ns_ip6_target primary_reselect 1)   [FAIL]
> >   	Current active slave is eth0 but not eth2
> > 
> > The ARP/NS monitor marks a slave down when it has received nothing for
> > too long. With arp_interval 100 and the default arp_missed_max, that is
> > about 250ms for the active slave (eth1) and 350ms for a backup slave
> > (eth0, eth2). Every 100ms, eth1 sends a probe: eth1 receives the reply,
> > and eth0/eth2 receive a copy forwarded by the gateway bridge. Once eth1
> > is down, its probes reach no one and no slave receives anything, so
> > eth1 normally times out first and the new active slave is picked by
> > prio:
> > 
> >   t=0    probe: eth1 gets the reply, eth0/eth2 get a copy
> >   t=10   test sets eth1 down
> >   t=300  monitor: eth1 idle 300ms -> down
> >                   eth0/eth2 idle 300ms -> up, eth2 picked by prio
> > 
> > But the test takes eth1 down right after bond_check_connection(), whose
> > ping replies only arrive on eth1:
> > 
> >   t=0    probe: eth1 gets the reply, eth0/eth2 get a copy
> >   t=70   ping reply on eth1 only
> >   t=85   test sets eth1 down
> >   t=300  monitor: eth1 idle 230ms -> still up
> >   t=400  monitor: eth1 idle 330ms -> down
> >                   eth2 idle 400ms -> down too
> > 
> > eth2 can then no longer be picked. eth0 becomes the active slave if it
> > happened to receive some other packet (e.g. an MLD report), otherwise
> > whichever slave comes back first does. With primary_reselect 1 or 2,
> > the bond keeps eth0 even after eth2 comes back.
> > 
> > Before taking the active slave down, wait two monitor intervals
> > (200ms), so that at least one more probe is sent after the last ping
> > reply and all slaves last received that probe. The miimon variants do
> > not need the wait, but the extra delay is negligible.
> 
> I'm afraid the waiting time is too strict, especially with a debug kernel
> since delays can happen.
> 
> Bjoern is also fixing[1] this issue by pinging a non-existent neighbor to
> keep traffic flowing. Would you like to test whether that works for you?
> 
> [1] https://lore.kernel.org/netdev/20261104142018.552135-1-doebel@amazon.de/

BTW, using ping may not able to triger the arp request in time. You can try
arping instead.

Thanks
Hangbin