All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Jarod Wilson <jarod@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Veaceslav Falico <vfalico@gmail.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Heesoon Kim <Heesoon.Kim@stratus.com>
Subject: Re: [PATCH net] bonding/802.3ad: fix slave link initialization transition states
Date: Fri, 24 May 2019 14:16:56 -0700	[thread overview]
Message-ID: <30882.1558732616@famine> (raw)
In-Reply-To: <20190524134928.16834-1-jarod@redhat.com>

Jarod Wilson <jarod@redhat.com> wrote:

>Once in a while, with just the right timing, 802.3ad slaves will fail to
>properly initialize, winding up in a weird state, with a partner system
>mac address of 00:00:00:00:00:00. This started happening after a fix to
>properly track link_failure_count tracking, where an 802.3ad slave that
>reported itself as link up in the miimon code, but wasn't able to get a
>valid speed/duplex, started getting set to BOND_LINK_FAIL instead of
>BOND_LINK_DOWN. That was the proper thing to do for the general "my link
>went down" case, but has created a link initialization race that can put
>the interface in this odd state.

	Reading back in the git history, the ultimate cause of this
"weird state" appears to be devices that assert NETDEV_UP prior to
actually being able to supply sane speed/duplex values, correct?

	Presuming that this is the case, I don't see that there's much
else to be done here, and so:

Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>

>The simple fix is to instead set the slave link to BOND_LINK_DOWN again,
>if the link has never been up (last_link_up == 0), so the link state
>doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed
>in this case, it simply hasn't been up yet, and this prevents the
>unnecessary state change from DOWN to FAIL and getting stuck in an init
>failure w/o a partner mac.
>
>Fixes: ea53abfab960 ("bonding/802.3ad: fix link_failure_count tracking")
>CC: Jay Vosburgh <j.vosburgh@gmail.com>
>CC: Veaceslav Falico <vfalico@gmail.com>
>CC: Andy Gospodarek <andy@greyhouse.net>
>CC: "David S. Miller" <davem@davemloft.net>
>CC: netdev@vger.kernel.org
>Tested-by: Heesoon Kim <Heesoon.Kim@stratus.com>
>Signed-off-by: Jarod Wilson <jarod@redhat.com>



>---
> drivers/net/bonding/bond_main.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 062fa7e3af4c..407f4095a37a 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3122,13 +3122,18 @@ static int bond_slave_netdev_event(unsigned long event,
> 	case NETDEV_CHANGE:
> 		/* For 802.3ad mode only:
> 		 * Getting invalid Speed/Duplex values here will put slave
>-		 * in weird state. So mark it as link-fail for the time
>-		 * being and let link-monitoring (miimon) set it right when
>-		 * correct speeds/duplex are available.
>+		 * in weird state. Mark it as link-fail if the link was
>+		 * previously up or link-down if it hasn't yet come up, and
>+		 * let link-monitoring (miimon) set it right when correct
>+		 * speeds/duplex are available.
> 		 */
> 		if (bond_update_speed_duplex(slave) &&
>-		    BOND_MODE(bond) == BOND_MODE_8023AD)
>-			slave->link = BOND_LINK_FAIL;
>+		    BOND_MODE(bond) == BOND_MODE_8023AD) {
>+			if (slave->last_link_up)
>+				slave->link = BOND_LINK_FAIL;
>+			else
>+				slave->link = BOND_LINK_DOWN;
>+		}
> 
> 		if (BOND_MODE(bond) == BOND_MODE_8023AD)
> 			bond_3ad_adapter_speed_duplex_changed(slave);
>-- 
>2.20.1
>

  reply	other threads:[~2019-05-24 21:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 13:49 [PATCH net] bonding/802.3ad: fix slave link initialization transition states Jarod Wilson
2019-05-24 21:16 ` Jay Vosburgh [this message]
2019-05-24 22:38   ` Mahesh Bandewar (महेश बंडेवार)
2019-05-25  3:21     ` Jarod Wilson
2019-05-25  2:40   ` Jarod Wilson
2019-05-26 20:29 ` 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=30882.1558732616@famine \
    --to=jay.vosburgh@canonical.com \
    --cc=Heesoon.Kim@stratus.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=jarod@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@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 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.