From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C921C5479D for ; Mon, 9 Jan 2023 11:57:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237047AbjAIL5O (ORCPT ); Mon, 9 Jan 2023 06:57:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237083AbjAIL5B (ORCPT ); Mon, 9 Jan 2023 06:57:01 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9172D12083; Mon, 9 Jan 2023 03:56:57 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id z11so12174407ede.1; Mon, 09 Jan 2023 03:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=R/pT23tJD4oTt91rYqRLukayxZ3L3T77mmbN65HM1ng=; b=Ua7tqnmz76QuyglO1osJpuYr+bgSHGx1SUhy9z7kPTzzillWXVYwuu3x4UQrgzc539 lBTDj1CsnpAZccHPWU6T1VGv8Wtm3df9updiX3VWX68jatXyYrcI0oB7C2B+gG8kPjYG QWhGgb8Au8oa0K2db+FwCP78MGf2UiqT3DIrioBJidIYg2SpgzrKAZJn8uX04Us5DgpY 9SESgaRE3UwVLiqGaMQ+NcAGCq3jgvrFu5/yL1iCUp7X7cDtHQ1dlcULZQQt8V0Ox+4a XbL+DUp1X8MeSKqjzXIEH8s9MT2Oodqy0uHatvzIa/P+PkXC0K4jjQnJ9lwxgPEoiPJw Vamw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R/pT23tJD4oTt91rYqRLukayxZ3L3T77mmbN65HM1ng=; b=lEBdbQIUAZuxXT3jPRmOFn+I+3h/UuXnyR1Jn7dTSddDeoHKGEESs1X7nynkDlzcLV Qc0Ujn827i9gDwOVxDo1Sgb3l0GJTSnI2e/G7MnNyJocFZw+9XBLz6H1H8yYvRX3E6yS plk7xY/+77RxIVCS3F+vqcmfrjp6GI7y1I5sHqcQjavFbL59jrQW4qg9KLYA5hzOaDnt 4cxmEdo8dxhwQ9LOps0Cd0Yzl7Pa8PeA6LDkXlJ3LwIlymZCBbwVkQu+q1aqZk+6lNI+ wEh2NDuievJWohEO7sEgIK3iFalPgbyFJFVLab+ywbEA/MUE6Q8Zy7g210Y1hRR6QW8C JbkQ== X-Gm-Message-State: AFqh2kq41I39VKkQXgQvU4I5EGzjmrLMceSql4fhotUhttaGUWinX+sE kbir/l1YTk8MF6YdapxOOmY= X-Google-Smtp-Source: AMrXdXupavywksOzsGvJd+G6X2+bu6gHlKAHWmcHS/M09LcC+/A+TIPVjFvCTyKAFkaLD9KNgwB6Yw== X-Received: by 2002:a05:6402:8cc:b0:499:8849:5fb2 with SMTP id d12-20020a05640208cc00b0049988495fb2mr3991753edz.28.1673265416050; Mon, 09 Jan 2023 03:56:56 -0800 (PST) Received: from skbuf ([188.27.185.38]) by smtp.gmail.com with ESMTPSA id g11-20020a056402428b00b004722d7e8c7csm3614118edc.14.2023.01.09.03.56.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Jan 2023 03:56:55 -0800 (PST) Date: Mon, 9 Jan 2023 13:56:53 +0200 From: Vladimir Oltean To: Ido Schimmel Cc: Tobias Waldekranz , davem@davemloft.net, kuba@kernel.org, Nikolay Aleksandrov , Andrew Lunn , Vivien Didelot , Florian Fainelli , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Russell King , Petr Machata , Ido Schimmel , Matt Johnston , Cooper Lees , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: [PATCH v5 net-next 01/15] net: bridge: mst: Multiple Spanning Tree (MST) mode Message-ID: <20230109115653.6yjijaj63n2v35lw@skbuf> References: <20220316150857.2442916-1-tobias@waldekranz.com> <20220316150857.2442916-2-tobias@waldekranz.com> <20230109100236.euq7iaaorqxrun7u@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 09, 2023 at 01:43:46PM +0200, Ido Schimmel wrote: > OK, thanks for confirming. Will send a patch later this week if Tobias > won't take care of it by then. First patch will probably be [1] to make > sure we dump the correct MST state to user space. It will also make it > easier to show the problem and validate the fix. > > [1] > diff --git a/net/bridge/br.c b/net/bridge/br.c > index 4f5098d33a46..f02a1ad589de 100644 > --- a/net/bridge/br.c > +++ b/net/bridge/br.c > @@ -286,7 +286,7 @@ int br_boolopt_get(const struct net_bridge *br, enum br_boolopt_id opt) > case BR_BOOLOPT_MCAST_VLAN_SNOOPING: > return br_opt_get(br, BROPT_MCAST_VLAN_SNOOPING_ENABLED); > case BR_BOOLOPT_MST_ENABLE: > - return br_opt_get(br, BROPT_MST_ENABLED); > + return br_mst_is_enabled(br); Well, this did report the correct MST state despite the incorrect static branch state, no? The users of br_mst_is_enabled(br) are broken, not those of br_opt_get(br, BROPT_MST_ENABLED). Anyway, I see there's a br_mst_is_enabled() and also a br_mst_enabled()?! One is used in the fast path and the other in the slow path. They should probably be merged, I guess. They both exist probably because somebody thought that the "if (!netif_is_bridge_master(dev))" test is redundant in the fast path. > default: > /* shouldn't be called with unsupported options */ > WARN_ON(1); > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h > index 75aff9bbf17e..7f0475f62d45 100644 > --- a/net/bridge/br_private.h > +++ b/net/bridge/br_private.h > @@ -1827,7 +1827,7 @@ static inline bool br_vlan_state_allowed(u8 state, bool learn_allow) > /* br_mst.c */ > #ifdef CONFIG_BRIDGE_VLAN_FILTERING > DECLARE_STATIC_KEY_FALSE(br_mst_used); > -static inline bool br_mst_is_enabled(struct net_bridge *br) > +static inline bool br_mst_is_enabled(const struct net_bridge *br) > { > return static_branch_unlikely(&br_mst_used) && > br_opt_get(br, BROPT_MST_ENABLED); > @@ -1845,7 +1845,7 @@ int br_mst_fill_info(struct sk_buff *skb, > int br_mst_process(struct net_bridge_port *p, const struct nlattr *mst_attr, > struct netlink_ext_ack *extack); > #else > -static inline bool br_mst_is_enabled(struct net_bridge *br) > +static inline bool br_mst_is_enabled(const struct net_bridge *br) > { > return false; > } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 93A7A81865 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1BEBC81342 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=R/pT23tJD4oTt91rYqRLukayxZ3L3T77mmbN65HM1ng=; b=Ua7tqnmz76QuyglO1osJpuYr+bgSHGx1SUhy9z7kPTzzillWXVYwuu3x4UQrgzc539 lBTDj1CsnpAZccHPWU6T1VGv8Wtm3df9updiX3VWX68jatXyYrcI0oB7C2B+gG8kPjYG QWhGgb8Au8oa0K2db+FwCP78MGf2UiqT3DIrioBJidIYg2SpgzrKAZJn8uX04Us5DgpY 9SESgaRE3UwVLiqGaMQ+NcAGCq3jgvrFu5/yL1iCUp7X7cDtHQ1dlcULZQQt8V0Ox+4a XbL+DUp1X8MeSKqjzXIEH8s9MT2Oodqy0uHatvzIa/P+PkXC0K4jjQnJ9lwxgPEoiPJw Vamw== Date: Mon, 9 Jan 2023 13:56:53 +0200 From: Vladimir Oltean Message-ID: <20230109115653.6yjijaj63n2v35lw@skbuf> References: <20220316150857.2442916-1-tobias@waldekranz.com> <20220316150857.2442916-2-tobias@waldekranz.com> <20230109100236.euq7iaaorqxrun7u@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Bridge] [PATCH v5 net-next 01/15] net: bridge: mst: Multiple Spanning Tree (MST) mode List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ido Schimmel Cc: Ivan Vecera , Andrew Lunn , Florian Fainelli , Jiri Pirko , Petr Machata , Nikolay Aleksandrov , bridge@lists.linux-foundation.org, Russell King , Vivien Didelot , Ido Schimmel , netdev@vger.kernel.org, Cooper Lees , Roopa Prabhu , kuba@kernel.org, Matt Johnston , davem@davemloft.net, linux-kernel@vger.kernel.org, Tobias Waldekranz On Mon, Jan 09, 2023 at 01:43:46PM +0200, Ido Schimmel wrote: > OK, thanks for confirming. Will send a patch later this week if Tobias > won't take care of it by then. First patch will probably be [1] to make > sure we dump the correct MST state to user space. It will also make it > easier to show the problem and validate the fix. > > [1] > diff --git a/net/bridge/br.c b/net/bridge/br.c > index 4f5098d33a46..f02a1ad589de 100644 > --- a/net/bridge/br.c > +++ b/net/bridge/br.c > @@ -286,7 +286,7 @@ int br_boolopt_get(const struct net_bridge *br, enum br_boolopt_id opt) > case BR_BOOLOPT_MCAST_VLAN_SNOOPING: > return br_opt_get(br, BROPT_MCAST_VLAN_SNOOPING_ENABLED); > case BR_BOOLOPT_MST_ENABLE: > - return br_opt_get(br, BROPT_MST_ENABLED); > + return br_mst_is_enabled(br); Well, this did report the correct MST state despite the incorrect static branch state, no? The users of br_mst_is_enabled(br) are broken, not those of br_opt_get(br, BROPT_MST_ENABLED). Anyway, I see there's a br_mst_is_enabled() and also a br_mst_enabled()?! One is used in the fast path and the other in the slow path. They should probably be merged, I guess. They both exist probably because somebody thought that the "if (!netif_is_bridge_master(dev))" test is redundant in the fast path. > default: > /* shouldn't be called with unsupported options */ > WARN_ON(1); > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h > index 75aff9bbf17e..7f0475f62d45 100644 > --- a/net/bridge/br_private.h > +++ b/net/bridge/br_private.h > @@ -1827,7 +1827,7 @@ static inline bool br_vlan_state_allowed(u8 state, bool learn_allow) > /* br_mst.c */ > #ifdef CONFIG_BRIDGE_VLAN_FILTERING > DECLARE_STATIC_KEY_FALSE(br_mst_used); > -static inline bool br_mst_is_enabled(struct net_bridge *br) > +static inline bool br_mst_is_enabled(const struct net_bridge *br) > { > return static_branch_unlikely(&br_mst_used) && > br_opt_get(br, BROPT_MST_ENABLED); > @@ -1845,7 +1845,7 @@ int br_mst_fill_info(struct sk_buff *skb, > int br_mst_process(struct net_bridge_port *p, const struct nlattr *mst_attr, > struct netlink_ext_ack *extack); > #else > -static inline bool br_mst_is_enabled(struct net_bridge *br) > +static inline bool br_mst_is_enabled(const struct net_bridge *br) > { > return false; > }