From: Paolo Abeni <pabeni@redhat.com>
To: Hangbin Liu <liuhangbin@gmail.com>, netdev@vger.kernel.org
Cc: Jay Vosburgh <jv@jvosburgh.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org, Liang Li <liali@redhat.com>
Subject: Re: [PATCHv2 net] bonding: fix multicast MAC address synchronization
Date: Tue, 12 Aug 2025 10:42:22 +0200 [thread overview]
Message-ID: <83bef808-8f50-4aaa-912e-6ccdb072918f@redhat.com> (raw)
In-Reply-To: <20250805080936.39830-1-liuhangbin@gmail.com>
On 8/5/25 10:09 AM, Hangbin Liu wrote:
> There is a corner case where the NS (Neighbor Solicitation) target is set to
> an invalid or unreachable address. In such cases, all the slave links are
> marked as down and set to *backup*. This causes the bond to add multicast MAC
> addresses to all slaves. The ARP monitor then cycles through each slave to
> probe them, temporarily marking as *active*.
>
> Later, if the NS target is changed or cleared during this probe cycle, the
> *active* slave will fail to remove its NS multicast address because
> bond_slave_ns_maddrs_del() only removes addresses from backup slaves.
> This leaves stale multicast MACs on the interface.
>
> To fix this, we move the NS multicast MAC address handling into
> bond_set_slave_state(), so every slave state transition consistently
> adds/removes NS multicast addresses as needed.
>
> We also ensure this logic is only active when arp_interval is configured,
> to prevent misconfiguration or accidental behavior in unsupported modes.
As noted by Jay in the previous revision, moving the handling into
bond_set_slave_state() could possibly impact a lot of scenarios, and
it's not obvious to me that restricting to arp_interval != 0 would be
sufficient.
I'm wondering if the issue could/should instead addressed explicitly
handling the mac swap for the active slave at NS target change time. WDYT?
Thanks,
Paolo
next prev parent reply other threads:[~2025-08-12 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 8:09 [PATCHv2 net] bonding: fix multicast MAC address synchronization Hangbin Liu
2025-08-12 8:42 ` Paolo Abeni [this message]
2025-08-13 4:04 ` Hangbin Liu
2025-09-09 3:42 ` Hangbin Liu
2026-03-11 2:41 ` Hangbin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83bef808-8f50-4aaa-912e-6ccdb072918f@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=liali@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.