Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp680516pxu; Mon, 23 Nov 2020 00:54:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEdYzAe6Ogh/pU1FKHQXL+cj2/ry0SRzjm+aotrjdmNvqcxbKkABKNGqJVBqVr3hWQ4wjo X-Received: by 2002:a17:906:a195:: with SMTP id s21mr41457287ejy.146.1606121693328; Mon, 23 Nov 2020 00:54:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606121693; cv=none; d=google.com; s=arc-20160816; b=MVWpOEHZ0siYv2FI2963+/KBeJbIxaBq5isQMRBqgt8XdckNnZExW8n2qof38rD6l9 2Im8lpjR6bKkrALW5Zm/k4FL9lyTBK3uGLiSm1kmauj7rjGX+3UNWf3lmta5jX/Q8X7H jBV7e0EkdWucgUcg9PSRa4C3eIPUiu9UfhPqEBi8JMQz6tEGMI+kxQjsKs4G+XR7P0k/ n/mnV5TGRGewelhpdzbtrcEqMmKE+OW6EcIVkR+rZLjZkRsct6DkBsknhKv2eZLFzC7A p6ljfV5GsiL/8kshXrmlP+W2HUg25BwkFsnmlYE8bBg1R1NryA7PCWX0PVhyvi3LBxGj L80w== 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:subject:cc:to:from:date :dkim-signature; bh=qdi2HhZ/hkHyKkGfU0FRMXdvsA6kz1Ug/WommlEtEbI=; b=paqDORzfPZwGZmhI2+b1T8NFZCs5PIOHVVeHLrTVbvoyzO5V0EteTGT56gXH4rJapk cLRhniCaZVbOQjE94MTnql4HkEq8vb9hHHjmEnMyt6Xy0JK5KUqoPqDS/U9WSaLU48Zz nKeYeN9LTwg5QaKoD3uy2t+oFayb7O1YS89EAxHXfuVQ7ET3t0vIhzWe0w5h001pMEg9 2S/tTUljHkbxQlWm8dIbQqPzcY7id3DB73orqonG0w9ucg//phmZ3IE5zN6EIMk7KK/x Oi1wybNRHxWBs33wfW09ynZMUkLEnMtQ+yArPvq+PZvO7pDwTaRmULdcZfrFeyI8FsXw Pz6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hRx6Xk/k"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l4si6419240edn.212.2020.11.23.00.54.30; Mon, 23 Nov 2020 00:54:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hRx6Xk/k"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727531AbgKWITg (ORCPT + 99 others); Mon, 23 Nov 2020 03:19:36 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:59865 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725320AbgKWITg (ORCPT ); Mon, 23 Nov 2020 03:19:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606119575; 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=qdi2HhZ/hkHyKkGfU0FRMXdvsA6kz1Ug/WommlEtEbI=; b=hRx6Xk/k+bmkuOBXm25+KOowWLF1CZoVTX59CjnViYtZiB0pitt7MSGTpr2lSjQr3LyWcD 15IZoHv+cPgNCyFshUtcdcy9Y8XItqfPoYMXcSKHcpQ63x2HFqRRnmFdnVIFamIJNXNHeD DUHxjIu/o1EUcK/FUsA+x7oSF0vES/k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-9-0OVgoA-NPPKBxjBe6aAQmQ-1; Mon, 23 Nov 2020 03:19:32 -0500 X-MC-Unique: 0OVgoA-NPPKBxjBe6aAQmQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AD2C787950F; Mon, 23 Nov 2020 08:19:27 +0000 (UTC) Received: from ceranb (unknown [10.40.192.251]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9C107620DE; Mon, 23 Nov 2020 08:19:22 +0000 (UTC) Date: Mon, 23 Nov 2020 09:19:21 +0100 From: Ivan Vecera To: Jarod Wilson Cc: linux-kernel@vger.kernel.org, Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , "David S. Miller" , Jakub Kicinski , Thomas Davis , netdev@vger.kernel.org Subject: Re: [PATCH net] bonding: fix feature flag setting at init time Message-ID: <20201123091921.0277d562@ceranb> In-Reply-To: <20201123031716.6179-1-jarod@redhat.com> References: <20201123031716.6179-1-jarod@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 22 Nov 2020 22:17:16 -0500 Jarod Wilson wrote: > Have run into a case where bond_option_mode_set() gets called before > hw_features has been filled in, and very bad things happen when > netdev_change_features() then gets called, because the empty hw_features > wipes out almost all features. Further reading of netdev feature flag > documentation suggests drivers aren't supposed to touch wanted_features, > so this changes bond_option_mode_set() to use netdev_increment_features() > and &= ~BOND_XFRM_FEATURES on mode changes and then only calling > netdev_features_change() if there was actually a change of features. This > specifically fixes bonding on top of mlxsw interfaces, and has been > regression-tested with ixgbe interfaces. This change also simplifies the > xfrm-specific code in bond_setup() a little bit as well. Hi Jarod, the reason is not correct... The problem is not with empty ->hw_features but with empty ->wanted_features. During bond device creation bond_newlink() is called. It calls bond_changelink() first and afterwards register_netdevice(). The problem is that ->wanted_features are initialized in register_netdevice() so during bond_changlink() call ->wanted_features is 0. So... bond_newlink() -> bond_changelink() -> __bond_opt_set() -> bond_option_mode_set() -> netdev_change_features() -> __netdev_update_features() features = netdev_get_wanted_features() { dev->features & ~dev->hw_features) | dev->wanted_features } dev->wanted_features is here zero so the rest of the expression clears a bunch of bits from dev->features... In case of mlxsw it is important that NETIF_F_HW_VLAN_CTAG_FILTER bit is cleared in bonding device because in this case vlan_add_rx_filter_info() does not call bond_vlan_rx_add_vid() so mlxsw_sp_port_add_vid() is not called as well. Later this causes a WARN in mlxsw_sp_inetaddr_port_vlan_event() because instance of mlxsw_sp_port_vlan does not exist as mlxsw_sp_port_add_vid() was not called. Btw. it should be enough to call existing snippet in bond_option_mode_set() only when device is already registered? E.g.: diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index 9abfaae1c6f7..ca4913fee5a9 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -768,11 +768,13 @@ static int bond_option_mode_set(struct bonding *bond, bond->params.tlb_dynamic_lb = 1; #ifdef CONFIG_XFRM_OFFLOAD - if (newval->value == BOND_MODE_ACTIVEBACKUP) - bond->dev->wanted_features |= BOND_XFRM_FEATURES; - else - bond->dev->wanted_features &= ~BOND_XFRM_FEATURES; - netdev_change_features(bond->dev); + if (dev->reg_state == NETREG_REGISTERED) { + if (newval->value == BOND_MODE_ACTIVEBACKUP) + bond->dev->wanted_features |= BOND_XFRM_FEATURES; + else + bond->dev->wanted_features &= ~BOND_XFRM_FEATURES; + netdev_change_features(bond->dev); + } #endif /* CONFIG_XFRM_OFFLOAD */ Thanks, Ivan