Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4114366imm; Sat, 21 Jul 2018 10:27:20 -0700 (PDT) X-Google-Smtp-Source: AAOMgpehvwVAlCP6FJL4uA5BLgT7nkxcy+3S081H4kp+105vuZoR8Q6WfxBb7MHwO30Zm70fwj8c X-Received: by 2002:a17:902:7106:: with SMTP id a6-v6mr6711259pll.28.1532194040251; Sat, 21 Jul 2018 10:27:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532194040; cv=none; d=google.com; s=arc-20160816; b=DdJgkM6zxUzYRv3bouTue97Bb13Sbr4yP4Q7mw2Ts74LZ3qauQnc4/8BfN7QSeVQ4G jlGX4F19CSjiCQ6y4bVi6zEaMnlp8PHZpwVXuR/pf3EGZ6ttxKYiTr4JPY59HyEtq0Y+ /qfCj+btfkCaeNHPcdDFt4wDOX709NnE4C2280EbW2Midojm0Na/zlWmSUx5ASp8hSQj QNKhFVsRa65hfJA1qL9J4S8zCKzJiHD7TVrrDOWFR3R6+qtqeYL+d4mbLKTq52sT5oHP SqZWX9Amgm6Ud+OuZaown4uQ5P2RKPX+7wmUq8LXma4BK90caRKxsT6AjYXli2w+42Ks 8dSQ== 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 :arc-authentication-results; bh=i8uqNZrBb5WTCEixlOLL66bHmC1kVCeap9OhQ2vWmTQ=; b=pk+UTPCbgx7xFGbUdF8QXaHtJ2MjWq5PMfWdBbjtLin69yypyV+F8JpDMijq8bypHm 3TBM5LdXB5tLHrEfM3rr/9UnIyZVMXKwvEANm/5QBkaN8CErIi8Wzd+CI4gDl3gIt0Yr 4DQwxljfHZxS7itC2LHks686HeQlOTTZJcjac3rU46bpK4ExS+wUtNU7Fr71niM1Y/Bw q7i7OHqkRVP/t13P1iIINUMqfLkrboFVAyR1/bzKyygN+Kn1ECBwfIIKcNksUbKU4q/c Bw3eyt7ZYWo/a2Fy3pf5tcKS+a5m0wxzFqmS7BxfbIrtplLTxl7Dp7WTJ+ib7cacvuUv YDRw== 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 m18-v6si4427400pgg.693.2018.07.21.10.27.05; Sat, 21 Jul 2018 10:27:20 -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 S1728012AbeGUSTo (ORCPT + 99 others); Sat, 21 Jul 2018 14:19:44 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:40206 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727562AbeGUSTn (ORCPT ); Sat, 21 Jul 2018 14:19:43 -0400 Received: from localhost (unknown [172.58.43.143]) (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 DA462122FED9D; Sat, 21 Jul 2018 10:26:16 -0700 (PDT) Date: Sat, 21 Jul 2018 10:26:15 -0700 (PDT) Message-Id: <20180721.102615.85495078941250538.davem@davemloft.net> To: jarod@redhat.com Cc: linux-kernel@vger.kernel.org, j.vosburgh@gmail.com, vfalico@gmail.com, andy@greyhouse.net, maheshb@google.com, netdev@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH net] bonding: set default miimon value for non-arp modes if not set From: David Miller In-Reply-To: <20180718184936.16037-1-jarod@redhat.com> References: <20180718184936.16037-1-jarod@redhat.com> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) 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]); Sat, 21 Jul 2018 10:26:17 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jarod Wilson Date: Wed, 18 Jul 2018 14:49:36 -0400 > For some time now, if you load the bonding driver and configure bond > parameters via sysfs using minimal config options, such as specifying > nothing but the mode, relying on defaults for everything else, modes > that cannot use arp monitoring (802.3ad, balance-tlb, balance-alb) all > wind up with both arp_interval=0 (as it should be) and miimon=0, which > means the miimon monitor thread never actually runs. This is particularly > problematic for 802.3ad. ... > I believe this became a major issue as of commit 4d2c0cda0744, which for > 802.3ad bonds, sets slave->link = BOND_LINK_DOWN, with a comment about > relying on link monitoring via miimon to set it correctly, but since the > miimon work queue never runs, the link just stays marked down. > > If we simply tweak bond_option_mode_set() slightly, we can check for the > non-arp modes having no miimon value set, and insert BOND_DEFAULT_MIIMON, > which gets things back in full working order. This problem exists as far > back as 4.14, and might be worth fixing in all stable trees since, though > the work-around is to simply specify an miimon value yourself. > > Reported-by: Bob Ball ... > Signed-off-by: Jarod Wilson Applied and queued up for -stable, thank you.