From: Hangbin Liu <hangbin.liu@linux.dev>
To: Timur Stukan <timur.stukan.linux@gmail.com>
Cc: netdev@vger.kernel.org, Hangbin Liu <liuhangbin@gmail.com>,
Fernando Fernandez Mancera <fmancera@suse.de>,
Jay Vosburgh <jv@jvosburgh.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] bonding: fix missing down path on speed/duplex failure after FAIL->UP
Date: Fri, 23 Oct 2026 15:48:43 +0800 [thread overview]
Message-ID: <atsRW-aYHeB-cEgi@fedora> (raw)
In-Reply-To: <20261022103821.89552-1-timur.stukan.linux@gmail.com>
On Thu, Oct 22, 2026 at 01:38:21PM +0300, Timur Stukan wrote:
> In bond_miimon_commit(), when a slave is proposed as BOND_LINK_UP but
> bond_update_speed_duplex() fails in bonding mode that needs speed/duplex
> (802.3ad, tlb, alb), the slave is set to BOND_LINK_DOWN directly. This
> bypasses bond_set_slave_link_state(), bond_miimon_link_change() and
> failover.
>
> This is fine for slave that coming from BOND_LINK_BACK, which was never
> brought up and is not in use. But since commit 1899bb325149 ("bonding:
> fix state transition issue in link monitoring") the commit phase also
> handles BOND_LINK_FAIL -> BOND_LINK_UP which means a slave that is still
> in use and may be curr_active_slave.
>
> If the link recovers within downdelay and goes down again before the
> commit phase reads speed/duplex, the slave is silently marked down while
> remaining the active slave in worst cases. In alb/tlb the bond MAC stays
> on the dead port, no failover happens and TLB/RLB state is not cleaned,
> so the bond stops passing traffic until that link comes back even though
> other slaves are up. A non-active slave is affected too, in alb, RLB
> clients assigned to it are not reassigned and become unreachable.
>
> Reproduced in tlb and alb mode with miimon=100 and downdelay=10000 by
> flapping a slave within downdelay and dropping it again before commit
> (a longer delay was added between inspect and commit to make window
> wider and easier to test):
> bond0: (slave enp0s3): link status down for interface, disabling it in 10000 ms
> bond0: (slave enp0s3): link status up again after 3400 ms
> bond0: (slave enp0s3): failed to get link speed/duplex
>
> procfs then shows the active slave with "MII Status: down" and "Link
> Failure Count: 0", and all traffic is lost.
>
> Fix this by recording the link state before the miimon commit and when
> the speed/duplex update fails for a slave coming from BOND_LINK_FAIL,
> taking it through the regular down path, including failover. The
> BOND_LINK_BACK case keeps the current behaviour. The down path is moved
> into bond_miimon_slave_down() so both callers share it.
>
> After the fix:
> bond0: (slave enp0s3): failed to get link speed/duplex
> bond0: (slave enp0s3): link status definitely down, disabling slave
> bond0: (slave enp0s4): making interface the new active one
>
> Fixes: 1899bb325149 ("bonding: fix state transition issue in link monitoring")
> Signed-off-by: Timur Stukan <timur.stukan.linux@gmail.com>
> ---
>
> Notes:
> sizeof(struct slave) grows from 608 to 616 bytes due to padding.
> I kept link_prev_state next to link/link_new_state for readability;
> it can be moved into the hole after 'delay' if preferred.
>
> drivers/net/bonding/bond_main.c | 53 ++++++++++++++++++++++-----------
> include/net/bonding.h | 1 +
> 2 files changed, 36 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 09aa45d71fab..602ad697a9c2 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2779,6 +2779,27 @@ static void bond_miimon_link_change(struct bonding *bond,
> }
> }
>
> +static bool bond_miimon_slave_down(struct bonding *bond,
> + struct slave *slave)
> +{
> + if (slave->link_failure_count < UINT_MAX)
> + slave->link_failure_count++;
> +
> + bond_set_slave_link_state(slave, BOND_LINK_DOWN,
> + BOND_SLAVE_NOTIFY_NOW);
> +
> + if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP ||
> + BOND_MODE(bond) == BOND_MODE_8023AD)
> + bond_set_slave_inactive_flags(slave,
> + BOND_SLAVE_NOTIFY_NOW);
> +
> + slave_info(bond->dev, slave->dev, "link status definitely down, disabling slave\n");
> +
> + bond_miimon_link_change(bond, slave, BOND_LINK_DOWN);
> +
> + return slave == rcu_access_pointer(bond->curr_active_slave);
> +}
> +
> static void bond_miimon_commit(struct bonding *bond)
> {
> struct slave *slave, *primary, *active;
> @@ -2807,10 +2828,21 @@ static void bond_miimon_commit(struct bonding *bond)
> err = bond_update_speed_duplex(slave);
> netdev_unlock_ops(slave->dev);
> if (err && bond_needs_speed_duplex(bond)) {
> - slave->link = BOND_LINK_DOWN;
Hmm, this issue only happens when link_state is on
netif_running(slave->dev) && netif_carrier_ok(slave->dev);
while !netif_device_present. Should we set the link up when device detached?
> if (net_ratelimit())
> slave_warn(bond->dev, slave->dev,
> "failed to get link speed/duplex\n");
> + /* Coming from FAIL, the slave is still in
> + * use and may be curr_active_slave, so take
> + * it through the full down path. Coming from
> + * DOWN/BACK, it was never brought up, so just
> + * revert it to DOWN.
> + */
> + if (slave->link_prev_state == BOND_LINK_FAIL) {
> + if (bond_miimon_slave_down(bond, slave))
> + do_failover = true;
> + continue;
> + }
> + slave->link = BOND_LINK_DOWN;
> continue;
> }
> bond_set_slave_link_state(slave, BOND_LINK_UP,
> @@ -2839,24 +2871,8 @@ static void bond_miimon_commit(struct bonding *bond)
> continue;
>
> case BOND_LINK_DOWN:
> - if (slave->link_failure_count < UINT_MAX)
> - slave->link_failure_count++;
> -
> - bond_set_slave_link_state(slave, BOND_LINK_DOWN,
> - BOND_SLAVE_NOTIFY_NOW);
> -
> - if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP ||
> - BOND_MODE(bond) == BOND_MODE_8023AD)
> - bond_set_slave_inactive_flags(slave,
> - BOND_SLAVE_NOTIFY_NOW);
> -
> - slave_info(bond->dev, slave->dev, "link status definitely down, disabling slave\n");
> -
> - bond_miimon_link_change(bond, slave, BOND_LINK_DOWN);
> -
> - if (slave == rcu_access_pointer(bond->curr_active_slave))
> + if (bond_miimon_slave_down(bond, slave))
> do_failover = true;
> -
> continue;
>
> case BOND_LINK_FAIL:
> @@ -2919,6 +2935,7 @@ static void bond_mii_monitor(struct work_struct *work)
>
> if (commit) {
> bond_for_each_slave(bond, slave, iter) {
> + slave->link_prev_state = slave->link;
> bond_commit_link_state(slave,
> BOND_SLAVE_NOTIFY_LATER);
> }
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index 598d56b1bc97..b2b102946fe1 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -165,6 +165,7 @@ struct slave {
> unsigned long target_last_arp_rx[BOND_MAX_ARP_TARGETS];
> s8 link; /* one of BOND_LINK_XXXX */
> s8 link_new_state; /* one of BOND_LINK_XXXX */
> + s8 link_prev_state; /* one of BOND_LINK_XXXX */
> u8 backup:1, /* indicates backup slave. Value corresponds with
> BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
> inactive:1, /* indicates inactive slave */
> --
> 2.43.0
>
Checking slave->inactive is not enough when user sets all_slaves_active, so
I'm not opposed to adding a new link state. The code looks good to me.
But let's see others opinion.
Thanks
Hangbin
prev parent reply other threads:[~2026-10-23 7:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 10:38 Timur Stukan
2026-10-23 7:48 ` Hangbin Liu [this message]
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=atsRW-aYHeB-cEgi@fedora \
--to=hangbin.liu@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fmancera@suse.de \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=timur.stukan.linux@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®