From: Jay Vosburgh <jv@jvosburgh.net>
To: Louis Scalbert <louis.scalbert@6wind.com>
Cc: netdev@vger.kernel.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, jonas.gorski@gmail.com
Subject: Re: [PATCH net v5 3/4] bonding: 3ad: fix mux port state on oper down
Date: Tue, 12 May 2026 12:09:45 +0200 [thread overview]
Message-ID: <150323.1778580585@vermin> (raw)
In-Reply-To: <20260506161144.465485-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 1247a1e048df..b531f68a24b0 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -1055,6 +1055,8 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> aggregator = rcu_dereference(port->aggregator);
> 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;
Repeating my comment here from the prior version of the patch
series, that this doesn't seem to comply with the standard. Bonding
should comply with IEEE 802.1AX-2014, and I do not want to mix and match
from different versions of the standard. The state machines differ
between versions, and I don't know if a half-and-half implementation
will function correctly. The 2020 edition of the standard diverges
significantly from prior versions, and bonding is very close to the 2014
standard.
-J
> } else {
> switch (port->sm_mux_state) {
> case AD_MUX_DETACHED:
>@@ -1202,6 +1204,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 (aggregator->is_active)
>--
>2.39.2
>
---
-Jay Vosburgh, jv@jvosburgh.net
next prev parent reply other threads:[~2026-05-12 10:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 16:11 [PATCH net v5 0/4] bonding: 3ad: fix carrier state with no usable slaves Louis Scalbert
2026-05-06 16:11 ` [PATCH net v5 1/4] bonding: 3ad: add lacp_strict configuration knob Louis Scalbert
2026-05-06 16:11 ` [PATCH net v5 2/4] bonding: 3ad: fix carrier when no usable slaves Louis Scalbert
2026-05-06 16:11 ` [PATCH net v5 3/4] bonding: 3ad: fix mux port state on oper down Louis Scalbert
2026-05-12 10:09 ` Jay Vosburgh [this message]
2026-05-18 15:39 ` Louis Scalbert
2026-05-06 16:11 ` [PATCH net v5 4/4] selftests: bonding: add test for lacp_strict mode Louis Scalbert
2026-05-06 16:33 ` Breno Leitao
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=150323.1778580585@vermin \
--to=jv@jvosburgh.net \
--cc=andrew+netdev@lunn.ch \
--cc=andy@greyhouse.net \
--cc=edumazet@google.com \
--cc=fbl@redhat.com \
--cc=jonas.gorski@gmail.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 \
/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.