From: Jay Vosburgh <jv@jvosburgh.net>
To: Louis Scalbert <louis.scalbert@6wind.com>
Cc: netdev@vger.kernel.org, stephen@networkplumber.org,
andrew+netdev@lunn.ch, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, fbl@redhat.com, andy@greyhouse.net,
shemminger@vyatta.com, maheshb@google.com
Subject: Re: [PATCH net v4 3/4] bonding: 3ad: fix mux port state on oper down
Date: Thu, 23 Apr 2026 13:00:19 -0700 [thread overview]
Message-ID: <1142168.1776974419@famine> (raw)
In-Reply-To: <20260417140505.3860237-4-louis.scalbert@6wind.com>
Louis Scalbert <louis.scalbert@6wind.com> wrote:
>When the bonding interface has carrier down due to the absence of
>usable slaves and a slave transitions from down to up, the bonding
>interface briefly goes carrier up, then down again, and finally up
>once LACP negotiates collecting and distributing on the port.
>
>When lacp_strict mode is on, the interface should not transition to
>carrier up until LACP negotiation is complete.
>
>This happens because the actor and partner port states remain in
>Collecting_Distributing when the port goes down. When the port
>comes back up, it temporarily remains in this state until LACP
>renegotiation occurs.
>
>Previously this was mostly cosmetic, but since the bonding carrier
>state may depend on the LACP negotiation state, it causes the
>interface to flap.
>
>Move an operationally down port to the Mux WAITING state and clear the
>Synchronization, Collecting, and Distributing states, in accordance with
>the 802.1AX Mux state machine diagram.
>
>Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad")
>Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
>---
> drivers/net/bonding/bond_3ad.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 9cf064243d58..bc2964ea11f5 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -1053,6 +1053,8 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
>
> if (port->sm_vars & AD_PORT_BEGIN) {
> port->sm_mux_state = AD_MUX_DETACHED;
>+ } else if (!port->is_enabled && port->sm_mux_state != AD_MUX_DETACHED) {
>+ port->sm_mux_state = AD_MUX_WAITING;
Technically, this is not exactly following the state machines.
The mux machine should transition to WAITING from DETACHED when
Selected == SELECTED or STANDBY, not for !is_enabled ("port_enabled" in
the standard). The check for !is_enabled happens in the receive
machine, and it would transition to PORT_DISABLED state (which clears
Synchronization).
I'm not sure if this is actually an issue or not; I need to read
the relevant bits again to make sure I understand how it's supposed to
work.
-J
> } else {
> switch (port->sm_mux_state) {
> case AD_MUX_DETACHED:
>@@ -1200,6 +1202,11 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> break;
> case AD_MUX_WAITING:
> port->sm_mux_timer_counter = __ad_timer_to_ticks(AD_WAIT_WHILE_TIMER, 0);
>+ port->actor_oper_port_state &= ~LACP_STATE_SYNCHRONIZATION;
>+ ad_disable_collecting_distributing(port,
>+ update_slave_arr);
>+ port->actor_oper_port_state &= ~LACP_STATE_COLLECTING;
>+ port->actor_oper_port_state &= ~LACP_STATE_DISTRIBUTING;
> break;
> case AD_MUX_ATTACHED:
> if (port->aggregator->is_active)
>--
>2.39.2
>
---
-Jay Vosburgh, jv@jvosburgh.net
next prev parent reply other threads:[~2026-04-23 20:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 14:05 [PATCH net v4 0/4] bonding: 3ad: fix carrier state with no usable slaves Louis Scalbert
2026-04-17 14:05 ` [PATCH net v4 1/4] bonding: 3ad: add lacp_strict configuration knob Louis Scalbert
2026-04-17 14:05 ` [PATCH net v4 2/4] bonding: 3ad: fix carrier when no usable slaves Louis Scalbert
2026-04-17 14:05 ` [PATCH net v4 3/4] bonding: 3ad: fix mux port state on oper down Louis Scalbert
2026-04-23 20:00 ` Jay Vosburgh [this message]
2026-04-17 14:05 ` [PATCH net v4 4/4] selftests: bonding: add test for lacp_strict mode Louis Scalbert
2026-04-17 19:27 ` Jakub Kicinski
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=1142168.1776974419@famine \
--to=jv@jvosburgh.net \
--cc=andrew+netdev@lunn.ch \
--cc=andy@greyhouse.net \
--cc=edumazet@google.com \
--cc=fbl@redhat.com \
--cc=kuba@kernel.org \
--cc=louis.scalbert@6wind.com \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shemminger@vyatta.com \
--cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox