From: "zhangsha (A)" <zhangsha.zhang@huawei.com>
To: "jay.vosburgh@canonical.com" <jay.vosburgh@canonical.com>,
"vfalico@gmail.com" <vfalico@gmail.com>,
"andy@greyhouse.net" <andy@greyhouse.net>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
yuehaibing <yuehaibing@huawei.com>,
hunongda <hunongda@huawei.com>,
"Chenzhendong (alex)" <alex.chen@huawei.com>
Subject: RE: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
Date: Wed, 18 Sep 2019 13:35:40 +0000 [thread overview]
Message-ID: <e333c8d2f3624a898a378eb1073f5f29@huawei.com> (raw)
In-Reply-To: <20190918130620.8556-1-zhangsha.zhang@huawei.com>
> -----Original Message-----
> From: zhangsha (A)
> Sent: 2019年9月18日 21:06
> To: jay.vosburgh@canonical.com; vfalico@gmail.com; andy@greyhouse.net;
> davem@davemloft.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> yuehaibing <yuehaibing@huawei.com>; hunongda <hunongda@huawei.com>;
> Chenzhendong (alex) <alex.chen@huawei.com>; zhangsha (A)
> <zhangsha.zhang@huawei.com>
> Subject: [PATCH v3] bonding: force enable lacp port after link state recovery for
> 802.3ad
>
> From: Sha Zhang <zhangsha.zhang@huawei.com>
>
> After the commit 334031219a84 ("bonding/802.3ad: fix slave link initialization
> transition states") merged, the slave's link status will be changed to
> BOND_LINK_FAIL from BOND_LINK_DOWN in the following scenario:
> - Driver reports loss of carrier and
> bonding driver receives NETDEV_DOWN notifier
> - slave's duplex and speed is zerod and
> its port->is_enabled is cleard to 'false';
> - Driver reports link recovery and
> bonding driver receives NETDEV_UP notifier;
> - If speed/duplex getting failed here, the link status
> will be changed to BOND_LINK_FAIL;
> - The MII monotor later recover the slave's speed/duplex
> and set link status to BOND_LINK_UP, but remains
> the 'port->is_enabled' to 'false'.
>
> In this scenario, the lacp port will not be enabled even its speed and duplex are
> valid. The bond will not send LACPDU's, and its state is 'AD_STATE_DEFAULTED'
> forever. The simplest fix I think is to call bond_3ad_handle_link_change() in
> bond_miimon_commit, this function can enable lacp after port slave speed
> check.
> As enabled, the lacp port can run its state machine normally after link recovery.
>
> Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
> ---
> drivers/net/bonding/bond_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 931d9d9..76324a5 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding
> *bond)
> */
> if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> slave->link == BOND_LINK_UP)
> -
> bond_3ad_adapter_speed_duplex_changed(slave);
> + bond_3ad_handle_link_change(slave,
> + BOND_LINK_UP);
> continue;
>
> case BOND_LINK_UP:
Hi, David,
I have replied your email for a while, I guess you may miss my email, so I resend it.
The following link address is the last email, please review the new one again, thank you.
https://patchwork.ozlabs.org/patch/1151915/
Last time, you doubted this is a driver specific problem,
I prefer to believe it's not because I find the commit 4d2c0cda,
its log says " Some NIC drivers don't have correct speed/duplex
settings at the time they send NETDEV_UP notification ...".
Anyway, I think the lacp status should be fixed correctly,
since link-monitoring (miimon) set SPEED/DUPLEX right here.
> --
> 1.8.3.1
next prev parent reply other threads:[~2019-09-18 13:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 13:06 [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad zhangsha.zhang
2019-09-18 13:35 ` zhangsha (A) [this message]
2019-09-19 8:11 ` Jay Vosburgh
2019-09-19 12:46 ` zhangsha (A)
2019-09-24 13:56 ` David Miller
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=e333c8d2f3624a898a378eb1073f5f29@huawei.com \
--to=zhangsha.zhang@huawei.com \
--cc=alex.chen@huawei.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=hunongda@huawei.com \
--cc=jay.vosburgh@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vfalico@gmail.com \
--cc=yuehaibing@huawei.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;
as well as URLs for NNTP newsgroup(s).