Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1739024ybn; Thu, 26 Sep 2019 01:14:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqyh/O/CnD+U8oNOfgiX3Ywl5Lua63LD/0GgsRxFptNPwmyHwjHT5a+vh0yn1DpJsMwxzelS X-Received: by 2002:a17:906:3108:: with SMTP id 8mr1940068ejx.11.1569485659810; Thu, 26 Sep 2019 01:14:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569485659; cv=none; d=google.com; s=arc-20160816; b=BbAl6uvuOrii8/gUZ9TVfgenDdft5Od8GwndxF/8yb0hGAAjZOa4xt70Ir68+vL5By twCkJPiEZUXufGrmUI/vNgvkHSVAbgc+K94cdPOKW8O06ukaMAOjJTlYpqAAPEQmVYbz IV3qHxkO8fIQIWfn5k1otxfn+ZVvBZS1evAj6Jv/280Qyq6cGMDGukVRz5YwCXAPGj4S IJIIvKcrw5OyEDPu0eGUV9M9mA84WfMrePvfbuvlUmRsiDguo59CINusT5TK67a4wMgh nZsZz5Ji000NQHHU/qIjmF5/qUpBFKwSVYXfzoLr/QKs3bZ7Li60yAtulHgcgw1ndcoX 9yeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=zHP9loYOHsb0/v6hwyEA47LfHeS2Awo4lZaRdyVp/Mw=; b=F+1hDDzIk3iUbFHAbMW0nNoz2WkfvpQuYHDBRL9bQUmJECk5b06a9T9ItR6Q1x+PQ/ 7eB4TV0bQkcIrIpaa8vnjcsIxjoakCOl2KZHUk/VbLruyko9nP6AWpGdhokIAWn/O1Dr 62YNt8gm51aDzJevr/D8hSQm9Bb9Fx2AOi+UYMBh6d0aNfpltzWcUYNOFP6knOVF0jss ensYeVcGSB+m/4XHm7GVaiD3OR0TgK/VPYDg/raqYQB9dQU+1b5wPJw0Sxjsc0roW3/X Tkjf/VPmcQC9sz4wn19Q3s7HXHpDVhpHxIMgdCsW7hvNUSBPvMtvonBFyZAqp18DLeau wJNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v26si609376eja.230.2019.09.26.01.13.56; Thu, 26 Sep 2019 01:14:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504994AbfIXN4y (ORCPT + 99 others); Tue, 24 Sep 2019 09:56:54 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:51840 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfIXN4x (ORCPT ); Tue, 24 Sep 2019 09:56:53 -0400 Received: from localhost (231-157-167-83.reverse.alphalink.fr [83.167.157.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id B22AC1525459D; Tue, 24 Sep 2019 06:56:51 -0700 (PDT) Date: Tue, 24 Sep 2019 15:56:50 +0200 (CEST) Message-Id: <20190924.155650.2089667667300458495.davem@davemloft.net> To: zhangsha.zhang@huawei.com Cc: jay.vosburgh@canonical.com, vfalico@gmail.com, andy@greyhouse.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, yuehaibing@huawei.com, hunongda@huawei.com, alex.chen@huawei.com Subject: Re: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad From: David Miller In-Reply-To: <20190918130620.8556-1-zhangsha.zhang@huawei.com> References: <20190918130620.8556-1-zhangsha.zhang@huawei.com> X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 24 Sep 2019 06:56:53 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Date: Wed, 18 Sep 2019 21:06:20 +0800 > From: Sha Zhang > > 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 Please work out with Jay and Aleksei how to properly fix this.