[6.18.y] bonding: please apply 11ea9b8a88dd and 70fc6649b36c

[6.18.y] bonding: please apply 11ea9b8a88dd and 70fc6649b36c

[Struan Bartlett]

Hello,

Please apply these two mainline commits (v7.0) to 6.18.y, in this
order:

  11ea9b8a88dd ("net: bonding: use workqueue to make sure peer notify updated in lacp mode")
  70fc6649b36c ("net: bonding: move bond_should_notify_peers, e.g. into rtnl lock block")

70fc6649b36c fixes a fault from 7a9214f3d88c ("bonding: ARP monitor
spams NETDEV_NOTIFY_PEERS notifiers") that is present in 6.18.y: in
active-backup mode with the ARP monitor, if bond_ab_arp_commit() fails
over while a peer notification is pending, bond_activebackup_arp_mon()
decrements send_peer_notif a second time, on the strength of
should_notify_peers computed before the failover. The counter wraps
from 0 to UINT_MAX, and the bond then sends NETDEV_NOTIFY_PEERS every
arp_interval for years. At boot this happens whenever a backup slave's
link comes up shortly before the primary's. On our servers FRR's zebra
counted each notification as the bond's link coming up, and ntpd never
rescanned its interfaces, so the clock went unsynchronised.

11ea9b8a88dd is a prerequisite: it adds bond_peer_notify_may_events(),
which 70fc6649b36c uses. Neither commit is tagged for stable. Both
apply cleanly, in this order, to v6.18.60 and v6.18.9.

Testing: Debian's 6.18.9-1~bpo13+1 kernel, booted in a VM, with the
bonding module built from v6.18.9 against Debian's headers. A
reproducer (two network namespaces: an active-backup bond with the ARP
monitor over two veths to a bridge holding the ARP target; it fails
over to the backup with num_grat_arp 255, then lets the ARP monitor
fail back to the primary with num_grat_arp 1 while a notification is
pending) counted the bond's NETDEV_NOTIFY_PEERS events for 3 s just
after the failback and, if there were any, for 3 s again 30 s later,
after the 255 would have run out. With arp_interval 100, a bond that
notifies on every ARP monitor run sends about 30 in 3 s:

  bonding module                         after  30 s later
  Debian's                                 29     28
  v6.18.9, unchanged                       29     29
  v6.18.9 + 11ea9b8a88dd + 70fc6649b36c     0      -

Neither commit applies to 6.12.y, so I am sending a minimal equivalent
patch for 6.12.y separately, with the reproducer:
"[PATCH 6.12.y] bonding: re-check pending peer notification under RTNL
in ARP monitor".

An AI coding assistant (Claude, model claude-opus-5-5) helped trace
the fault, wrote this request and the reproducer, and built and ran
the tests above under my direction. I have reviewed this request.

Thank you,

Struan Bartlett

Re: [6.18.y] bonding: please apply 11ea9b8a88dd and 70fc6649b36c

[Greg KH]

On Fri, Oct 30, 2026 at 10:51:18PM +0000, Struan Bartlett wrote:
> Hello,
> 
> Please apply these two mainline commits (v7.0) to 6.18.y, in this
> order:
> 
>   11ea9b8a88dd ("net: bonding: use workqueue to make sure peer notify updated in lacp mode")
>   70fc6649b36c ("net: bonding: move bond_should_notify_peers, e.g. into rtnl lock block")
> 
> 70fc6649b36c fixes a fault from 7a9214f3d88c ("bonding: ARP monitor
> spams NETDEV_NOTIFY_PEERS notifiers") that is present in 6.18.y: in
> active-backup mode with the ARP monitor, if bond_ab_arp_commit() fails
> over while a peer notification is pending, bond_activebackup_arp_mon()
> decrements send_peer_notif a second time, on the strength of
> should_notify_peers computed before the failover. The counter wraps
> from 0 to UINT_MAX, and the bond then sends NETDEV_NOTIFY_PEERS every
> arp_interval for years. At boot this happens whenever a backup slave's
> link comes up shortly before the primary's. On our servers FRR's zebra
> counted each notification as the bond's link coming up, and ntpd never
> rescanned its interfaces, so the clock went unsynchronised.
> 
> 11ea9b8a88dd is a prerequisite: it adds bond_peer_notify_may_events(),
> which 70fc6649b36c uses. Neither commit is tagged for stable. Both
> apply cleanly, in this order, to v6.18.60 and v6.18.9.
> 
> Testing: Debian's 6.18.9-1~bpo13+1 kernel, booted in a VM, with the
> bonding module built from v6.18.9 against Debian's headers. A
> reproducer (two network namespaces: an active-backup bond with the ARP
> monitor over two veths to a bridge holding the ARP target; it fails
> over to the backup with num_grat_arp 255, then lets the ARP monitor
> fail back to the primary with num_grat_arp 1 while a notification is
> pending) counted the bond's NETDEV_NOTIFY_PEERS events for 3 s just
> after the failback and, if there were any, for 3 s again 30 s later,
> after the 255 would have run out. With arp_interval 100, a bond that
> notifies on every ARP monitor run sends about 30 in 3 s:
> 
>   bonding module                         after  30 s later
>   Debian's                                 29     28
>   v6.18.9, unchanged                       29     29
>   v6.18.9 + 11ea9b8a88dd + 70fc6649b36c     0      -
> 
> Neither commit applies to 6.12.y, so I am sending a minimal equivalent
> patch for 6.12.y separately, with the reproducer:
> "[PATCH 6.12.y] bonding: re-check pending peer notification under RTNL
> in ARP monitor".
> 
> An AI coding assistant (Claude, model claude-opus-5-5) helped trace
> the fault, wrote this request and the reproducer, and built and ran
> the tests above under my direction. I have reviewed this request.
> 
> Thank you,
> 
> Struan Bartlett
> 

Now queued up, thanks.

greg k-h