From: Hangbin Liu <hangbin.liu@linux.dev>
To: Jay Vosburgh <jv@jvosburgh.net>
Cc: Timur Stukan <timur.stukan.linux@gmail.com>,
netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
Fernando Fernandez Mancera <fmancera@suse.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] bonding: fix missing down path on speed/duplex failure after FAIL->UP
Date: Fri, 30 Oct 2026 09:39:00 +0800 [thread overview]
Message-ID: <auP1JledouywUMci@bogon> (raw)
In-Reply-To: <91955.1793289071@vermin>
Hi Jay,
On Thu, Oct 29, 2026 at 10:51:11AM -0500, Jay Vosburgh wrote:
> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >index 7019e5d8fdc8..9bafcddbb453 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >
> > case BOND_LINK_FAIL:
> >@@ -2919,6 +2935,12 @@ static void bond_mii_monitor(struct work_struct *work)
> >
> > if (commit) {
> > bond_for_each_slave(bond, slave, iter) {
> >+ /* UP state is committed by bond_miimon_commit()
> >+ * after the speed and duplex check, so that it
> >+ * can still see the previous link state.
> >+ */
> >+ if (slave->link_new_state == BOND_LINK_UP)
> >+ continue;
> > bond_commit_link_state(slave,
> > BOND_SLAVE_NOTIFY_LATER);
>
> Reading bond_commit_link_state(), for this call site, all it
> really does is slave->link = slave->link_new_state, when link_new_state
> != BOND_LINK_NOCHAGE. The changes to ->should_notify_link only matter
> for the ARP monitor, so that part is effectively a no-op here.
+1
>
> Therefore, I wonder if it would be cleaner overall to not do the
> bond_commit_link_state here at all, but instead keep what you've added
> in the BOND_LINK_UP part of bond_miimon_commit, and then add calls to
> bond_set_slave_link_state(slave, ..., BOND_SLAVE_NOTIFY_LATER) to the
> BOND_LINK_FAIL/BOND_LINK_BACK case to make the change stick.
>
> A quick hack patch that I have not tested to hopefully
> illustrate what I mean:
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 756d79281ffc..5fb215fa85f6 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2877,6 +2877,8 @@ static void bond_miimon_commit(struct bonding *bond)
>
> case BOND_LINK_FAIL:
> case BOND_LINK_BACK:
> + bond_set_slave_link_state(slave, slave->link_new_state,
> + BOND_SLAVE_NOTIFY_LATER);
- bond_set_slave_link_state(slave, slave->link_new_state, BOND_SLAVE_NOTIFY_LATER)
- bond_propose_link_state(slave, slave->link_new_state)
- slave->link_new_state = slave->link_new_state
This looks like a no-op here.
Maybe just call bond_commit_link_state()?
The bond_set_slave_link_state() in bond_miimon_commit() seems also have this
issue.
Thanks
Hangbin
> slave_dbg(bond->dev, slave->dev, "link_new_state %d on slave\n",
> slave->link_new_state);
> continue;
> @@ -2933,19 +2935,8 @@ static void bond_mii_monitor(struct work_struct *work)
> goto re_arm;
> }
>
> - if (commit) {
> - bond_for_each_slave(bond, slave, iter) {
> - /* UP state is committed by bond_miimon_commit()
> - * after the speed and duplex check, so that it
> - * can still see the previous link state.
> - */
> - if (slave->link_new_state == BOND_LINK_UP)
> - continue;
> - bond_commit_link_state(slave,
> - BOND_SLAVE_NOTIFY_LATER);
> - }
> + if (commit)
> bond_miimon_commit(bond);
> - }
>
> if (bond->send_peer_notif)
> bond_peer_notify_may_events(bond, true);
>
>
> Thoughts?
>
> -J
>
> ---
> -Jay Vosburgh, jv@jvosburgh.net
prev parent reply other threads:[~2026-10-30 1:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 10:47 Timur Stukan
2026-10-29 1:49 ` Hangbin Liu
2026-10-29 15:51 ` Jay Vosburgh
2026-10-30 1:39 ` 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=auP1JledouywUMci@bogon \
--to=hangbin.liu@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fmancera@suse.de \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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®