Message ID | cb89b92af89973ee049a696c362b4a2abfdd9b82.1668800711.git.jtoppins@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp399942wrr; Fri, 18 Nov 2022 12:44:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf74WhMZhCFifI8/3RztVcMIxdGzdPc40jQKV6qLoHk2BMaXe8itTv38NbT1a8iT0OStYBXb X-Received: by 2002:a17:902:7b96:b0:188:6300:57a7 with SMTP id w22-20020a1709027b9600b00188630057a7mr1148431pll.105.1668804267142; Fri, 18 Nov 2022 12:44:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668804267; cv=none; d=google.com; s=arc-20160816; b=fHrDDqsluVVzFr4j/V/T1pzuR8dtulj31RNsB1RLhb96potxaeOh6q+r+FzQlSSa5W G6sOxWjj26KI8PD8Uj94/wxFyhmlSsWyZ6NYNNAIRJixu/zmAYhd94bmD/KB907pvXNQ K+oSNHry8B+5M6e+uj/GdeHNMyRIMT3O379QA66pfR5vxXGdkzi5B6tRwHn6cxsuVQMZ pfPwtd22RTSK2MMs6A2VyQFyn4enjotz1IzAVt4hD3TkFV8I+9Gn7mHzc0DN2iW49vNw oMD7JjQFWorAGtPjLX6bSL8t9mO8i1/ZM3FBHd3QUg4qz9+qDprZtGgHFZl/rFUbj668 8g3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=XNX9PG9IctWJjJf9clHPMrPEcd0dTkPsQmVfvpSx6A4=; b=UZpPRcyJYnu472iClYqkAggFmedxBMWVGsoPPKwpSw2Gg8Q32YIJN5bXyIG4FgRmht W8l2PbXXBF6/oSaSoiKQah9OY1/6VjOq0RaGhJmWy8YOvjJTeUKSGvgx7SyoNknjLFMb BD7JpXlM4k5G7xLqJzghISo3jHyB8noiLqRpA5DXltV4g/q2U7FqvHNYNY2+L5rBewQA 7Ok6QzG53OsV/nMLc3hmnce5vVxDgHFEHHy+2VJ1mMZUZAf1G8L/rMDrKajfP6EMpdtI WljbmqCKgNE9hv6/lYf3eF6g2VvrubdC3YdHZi4LuyR7dk43SnotAYNU8G6CS5D4jzTs 7nNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="dN/OM+fF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x189-20020a6386c6000000b00476c4e19578si1489610pgd.600.2022.11.18.12.44.14; Fri, 18 Nov 2022 12:44:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="dN/OM+fF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231425AbiKRUbd (ORCPT <rfc822;kkmonlee@gmail.com> + 99 others); Fri, 18 Nov 2022 15:31:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231202AbiKRUb3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 18 Nov 2022 15:31:29 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47F766304 for <linux-kernel@vger.kernel.org>; Fri, 18 Nov 2022 12:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668803431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XNX9PG9IctWJjJf9clHPMrPEcd0dTkPsQmVfvpSx6A4=; b=dN/OM+fFLJCgHXJrXLujT/vu5xCd6IffOEAD/sdRnrRMB3xEMKAvmWJAZV8tXHamg1fE4u uUM6qm/Nhht2VqyLFe78c/G8BE5kOkAUIaIiZIpLmVFRCucglgVvD/yv3PLVDPo/kdgd++ WgMONtPaWSxeZYE/N8zQKItijqGiesA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-vQiax6awNCK70oeC74Zx4Q-1; Fri, 18 Nov 2022 15:30:26 -0500 X-MC-Unique: vQiax6awNCK70oeC74Zx4Q-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E0C7185A794; Fri, 18 Nov 2022 20:30:25 +0000 (UTC) Received: from jtoppins.rdu.csb (unknown [10.22.10.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id AB4F4492B04; Fri, 18 Nov 2022 20:30:24 +0000 (UTC) From: Jonathan Toppins <jtoppins@redhat.com> To: netdev@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com> Cc: Veaceslav Falico <vfalico@gmail.com>, Andy Gospodarek <andy@greyhouse.net>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org Subject: [PATCH net-next 2/2] bonding: fix link recovery in mode 2 when updelay is nonzero Date: Fri, 18 Nov 2022 15:30:13 -0500 Message-Id: <cb89b92af89973ee049a696c362b4a2abfdd9b82.1668800711.git.jtoppins@redhat.com> In-Reply-To: <cover.1668800711.git.jtoppins@redhat.com> References: <cover.1668800711.git.jtoppins@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749868103442465671?= X-GMAIL-MSGID: =?utf-8?q?1749868103442465671?= |
Series |
[net-next,1/2] selftests: bonding: up/down delay w/ slave link flapping
|
|
Commit Message
Jonathan Toppins
Nov. 18, 2022, 8:30 p.m. UTC
Before this change when a bond in mode 2 lost link, all of its slaves
lost link, the bonding device would never recover even after the
expiration of updelay. This change removes the updelay when the bond
currently has no usable links. Conforming to bonding.txt section 13.1
paragraph 4.
Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
---
drivers/net/bonding/bond_main.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Comments
Hello, On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: > Before this change when a bond in mode 2 lost link, all of its slaves > lost link, the bonding device would never recover even after the > expiration of updelay. This change removes the updelay when the bond > currently has no usable links. Conforming to bonding.txt section 13.1 > paragraph 4. > > Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> Why are you targeting net-next? This looks like something suitable to the -net tree to me. If, so could you please include a Fixes tag? Note that we can add new self-tests even via the -net tree. Thanks, Paolo
On 11/22/22 05:59, Paolo Abeni wrote: > Hello, > > On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: >> Before this change when a bond in mode 2 lost link, all of its slaves >> lost link, the bonding device would never recover even after the >> expiration of updelay. This change removes the updelay when the bond >> currently has no usable links. Conforming to bonding.txt section 13.1 >> paragraph 4. >> >> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> > > Why are you targeting net-next? This looks like something suitable to > the -net tree to me. If, so could you please include a Fixes tag? > > Note that we can add new self-tests even via the -net tree. > I could not find a reasonable fixes tag for this, hence why I targeted the net-next tree. -Jon
On Tue, 2022-11-22 at 08:36 -0500, Jonathan Toppins wrote: > On 11/22/22 05:59, Paolo Abeni wrote: > > Hello, > > > > On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: > > > Before this change when a bond in mode 2 lost link, all of its slaves > > > lost link, the bonding device would never recover even after the > > > expiration of updelay. This change removes the updelay when the bond > > > currently has no usable links. Conforming to bonding.txt section 13.1 > > > paragraph 4. > > > > > > Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> > > > > Why are you targeting net-next? This looks like something suitable to > > the -net tree to me. If, so could you please include a Fixes tag? > > > > Note that we can add new self-tests even via the -net tree. > > > > I could not find a reasonable fixes tag for this, hence why I targeted > the net-next tree. When in doubt I think it's preferrable to point out a commit surely affected by the issue - even if that is possibly not the one introducing the issue - than no Fixes as all. The lack of tag will make more difficult the work for stable teams. In this specific case I think that: Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") should be ok, WDYT? if you agree would you mind repost for -net? Thanks, Paolo
On 11/22/22 09:45, Paolo Abeni wrote: > On Tue, 2022-11-22 at 08:36 -0500, Jonathan Toppins wrote: >> On 11/22/22 05:59, Paolo Abeni wrote: >>> Hello, >>> >>> On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: >>>> Before this change when a bond in mode 2 lost link, all of its slaves >>>> lost link, the bonding device would never recover even after the >>>> expiration of updelay. This change removes the updelay when the bond >>>> currently has no usable links. Conforming to bonding.txt section 13.1 >>>> paragraph 4. >>>> >>>> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> >>> >>> Why are you targeting net-next? This looks like something suitable to >>> the -net tree to me. If, so could you please include a Fixes tag? >>> >>> Note that we can add new self-tests even via the -net tree. >>> >> >> I could not find a reasonable fixes tag for this, hence why I targeted >> the net-next tree. > > When in doubt I think it's preferrable to point out a commit surely > affected by the issue - even if that is possibly not the one > introducing the issue - than no Fixes as all. The lack of tag will make > more difficult the work for stable teams. > > In this specific case I think that: > > Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") > > should be ok, WDYT? if you agree would you mind repost for -net? > > Thanks, > > Paolo > Yes that looks like a good one. I will repost to -net a v2 that includes changes to reduce the number of icmp echos sent before failing the test. Thanks, -Jon
On 22/11/2022 17:37, Jonathan Toppins wrote: > On 11/22/22 09:45, Paolo Abeni wrote: >> On Tue, 2022-11-22 at 08:36 -0500, Jonathan Toppins wrote: >>> On 11/22/22 05:59, Paolo Abeni wrote: >>>> Hello, >>>> >>>> On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: >>>>> Before this change when a bond in mode 2 lost link, all of its slaves >>>>> lost link, the bonding device would never recover even after the >>>>> expiration of updelay. This change removes the updelay when the bond >>>>> currently has no usable links. Conforming to bonding.txt section 13.1 >>>>> paragraph 4. >>>>> >>>>> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> >>>> >>>> Why are you targeting net-next? This looks like something suitable to >>>> the -net tree to me. If, so could you please include a Fixes tag? >>>> >>>> Note that we can add new self-tests even via the -net tree. >>>> >>> >>> I could not find a reasonable fixes tag for this, hence why I targeted >>> the net-next tree. >> >> When in doubt I think it's preferrable to point out a commit surely >> affected by the issue - even if that is possibly not the one >> introducing the issue - than no Fixes as all. The lack of tag will make >> more difficult the work for stable teams. >> >> In this specific case I think that: >> >> Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") >> >> should be ok, WDYT? if you agree would you mind repost for -net? >> >> Thanks, >> >> Paolo >> > > Yes that looks like a good one. I will repost to -net a v2 that includes changes to reduce the number of icmp echos sent before failing the test. > > Thanks, > -Jon > One minor nit - could you please change "mode 2" to "mode balance-xor" ? It saves reviewers some grepping around the code to see what is mode 2. Obviously one has to dig in the code to see how it's affected, but still it is a bit more understandable. It'd be nice to add more as to why the link is not recovered, I get it after reading the code, but it would be nice to include a more detailed explanation in the commit message as well. Thanks, Nik
On 22/11/2022 23:12, Nikolay Aleksandrov wrote: > On 22/11/2022 17:37, Jonathan Toppins wrote: >> On 11/22/22 09:45, Paolo Abeni wrote: >>> On Tue, 2022-11-22 at 08:36 -0500, Jonathan Toppins wrote: >>>> On 11/22/22 05:59, Paolo Abeni wrote: >>>>> Hello, >>>>> >>>>> On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: >>>>>> Before this change when a bond in mode 2 lost link, all of its slaves >>>>>> lost link, the bonding device would never recover even after the >>>>>> expiration of updelay. This change removes the updelay when the bond >>>>>> currently has no usable links. Conforming to bonding.txt section 13.1 >>>>>> paragraph 4. >>>>>> >>>>>> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> >>>>> >>>>> Why are you targeting net-next? This looks like something suitable to >>>>> the -net tree to me. If, so could you please include a Fixes tag? >>>>> >>>>> Note that we can add new self-tests even via the -net tree. >>>>> >>>> >>>> I could not find a reasonable fixes tag for this, hence why I targeted >>>> the net-next tree. >>> >>> When in doubt I think it's preferrable to point out a commit surely >>> affected by the issue - even if that is possibly not the one >>> introducing the issue - than no Fixes as all. The lack of tag will make >>> more difficult the work for stable teams. >>> >>> In this specific case I think that: >>> >>> Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") >>> >>> should be ok, WDYT? if you agree would you mind repost for -net? >>> >>> Thanks, >>> >>> Paolo >>> >> >> Yes that looks like a good one. I will repost to -net a v2 that includes changes to reduce the number of icmp echos sent before failing the test. >> >> Thanks, >> -Jon >> > > One minor nit - could you please change "mode 2" to "mode balance-xor" ? > It saves reviewers some grepping around the code to see what is mode 2. > Obviously one has to dig in the code to see how it's affected, but still > it is a bit more understandable. It'd be nice to add more as to why the link is not recovered, > I get it after reading the code, but it would be nice to include a more detailed explanation in the > commit message as well. > > Thanks, > Nik > Ah, I just noticed I'm late to the party. :) Nevermind my comments, no need for a v3.
On 11/22/22 16:15, Nikolay Aleksandrov wrote: > On 22/11/2022 23:12, Nikolay Aleksandrov wrote: >> On 22/11/2022 17:37, Jonathan Toppins wrote: >>> On 11/22/22 09:45, Paolo Abeni wrote: >>>> On Tue, 2022-11-22 at 08:36 -0500, Jonathan Toppins wrote: >>>>> On 11/22/22 05:59, Paolo Abeni wrote: >>>>>> Hello, >>>>>> >>>>>> On Fri, 2022-11-18 at 15:30 -0500, Jonathan Toppins wrote: >>>>>>> Before this change when a bond in mode 2 lost link, all of its slaves >>>>>>> lost link, the bonding device would never recover even after the >>>>>>> expiration of updelay. This change removes the updelay when the bond >>>>>>> currently has no usable links. Conforming to bonding.txt section 13.1 >>>>>>> paragraph 4. >>>>>>> >>>>>>> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> >>>>>> >>>>>> Why are you targeting net-next? This looks like something suitable to >>>>>> the -net tree to me. If, so could you please include a Fixes tag? >>>>>> >>>>>> Note that we can add new self-tests even via the -net tree. >>>>>> >>>>> >>>>> I could not find a reasonable fixes tag for this, hence why I targeted >>>>> the net-next tree. >>>> >>>> When in doubt I think it's preferrable to point out a commit surely >>>> affected by the issue - even if that is possibly not the one >>>> introducing the issue - than no Fixes as all. The lack of tag will make >>>> more difficult the work for stable teams. >>>> >>>> In this specific case I think that: >>>> >>>> Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave") >>>> >>>> should be ok, WDYT? if you agree would you mind repost for -net? >>>> >>>> Thanks, >>>> >>>> Paolo >>>> >>> >>> Yes that looks like a good one. I will repost to -net a v2 that includes changes to reduce the number of icmp echos sent before failing the test. >>> >>> Thanks, >>> -Jon >>> >> >> One minor nit - could you please change "mode 2" to "mode balance-xor" ? >> It saves reviewers some grepping around the code to see what is mode 2. >> Obviously one has to dig in the code to see how it's affected, but still >> it is a bit more understandable. It'd be nice to add more as to why the link is not recovered, >> I get it after reading the code, but it would be nice to include a more detailed explanation in the >> commit message as well. >> >> Thanks, >> Nik >> > > Ah, I just noticed I'm late to the party. :) > Nevermind my comments, no need for a v3. > If there are other issues with v2. I will gladly include these comments in a v3. Thanks, -Jon
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 1cd4e71916f8..6c4348245d1f 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -2529,7 +2529,16 @@ static int bond_miimon_inspect(struct bonding *bond) struct slave *slave; bool ignore_updelay; - ignore_updelay = !rcu_dereference(bond->curr_active_slave); + if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP) { + ignore_updelay = !rcu_dereference(bond->curr_active_slave); + } else { + struct bond_up_slave *usable_slaves; + + usable_slaves = rcu_dereference(bond->usable_slaves); + + if (usable_slaves && usable_slaves->count == 0) + ignore_updelay = true; + } bond_for_each_slave_rcu(bond, slave, iter) { bond_propose_link_state(slave, BOND_LINK_NOCHANGE);