Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1164788pxb; Wed, 10 Feb 2021 01:29:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8ilbZhx/Jvk1M63RhC/4RcjBAFgg1lFDZI3M3OSLzyks+utaY8moi480bM1KPpcBjT8P8 X-Received: by 2002:a17:906:3395:: with SMTP id v21mr2021401eja.331.1612949340834; Wed, 10 Feb 2021 01:29:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612949340; cv=none; d=google.com; s=arc-20160816; b=Plz+73gWSnFkvUVrXRXIYip9cnOW1YKzRJwZymjcLH65rbdBBWHKsFGtY0wqMp06Tm TpQBge+I3f4zL9nONZ0RQ69FTWrCQ1LlSHj5pacV3I29ul5QrxwQAbyW0Cxb1jR9Bqb0 UwKSi+HkWmR8SxjUZtbIPulI/f3qvjbW31SYXALuGxCGFMvPpI2gBDz4L5QHpg0zRccy MBos/oRu3W7wc5BX0nbERXbOkf0HZlRX25CRBG/kW2DR4Cb2b3uHVV4eCo/EkLXSuOQZ 7AyRkjxBS4moFKq86bClKDXlWDddokT/T+LdshAJl9L9Hsy/S6dx+QQYik+hB5tpzFjQ Ts+A== 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=oxbGJHr2KscLJg3Jp7wNmlUMCtlznjqgTotwuzodnos=; b=TzyFes7iIhh5UkRTO2sX1DRCZvHaAn7Z9rJrHVOaALvRP1lwkGhU1JxW92dRmhEpzI nShu0Z9TX6GrgHii+XFEb5StivSZ04gcUo5tirz8/eb3ELs3cFx8rN6k+P2JYzeYR5tO LlhhsUtC1gab0Cn0IfgdDDDStEuKM2dDhUyZn+bNKHTBOGlcabPhM2CI8RZ8eELJ4smy h6QWiPS+K0JQ5Ew3zUaF4vw4+prbSUP5/0zEt6Uiq1BZNjZ+jWXAZPV27RkmvFVVeSgp 2B9QkKiFjyPE1RhV5LU8HU6EU1SVgTy75/ZNod7gxInVSJLIgZJdSPTk++lUsnzcR3q0 flWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EQtiSoYI; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v17si981507ejy.545.2021.02.10.01.28.37; Wed, 10 Feb 2021 01:29:00 -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=@gmail.com header.s=20161025 header.b=EQtiSoYI; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230243AbhBJJYW (ORCPT + 99 others); Wed, 10 Feb 2021 04:24:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229937AbhBJJUx (ORCPT ); Wed, 10 Feb 2021 04:20:53 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5DC2C061794; Wed, 10 Feb 2021 01:19:20 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id bl23so2827399ejb.5; Wed, 10 Feb 2021 01:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oxbGJHr2KscLJg3Jp7wNmlUMCtlznjqgTotwuzodnos=; b=EQtiSoYI3Xw5uRAtZwkexizLRt1f3HgSFAUttbijJLbYb7M9rB3WAG5SyY/tmTW/VS p9ZFxnK77Gq1ff6vY0astsy6Ra7I3k1DGWtULUD8v+gPV0hnOHKNIwoGLK4//rkFAqZD Sb4wTXl+ndq87klUNQYtyEm/WI2OMW1gB1l3Qt0dYnUsGoYPF3q+wy7+TrHjC/Xem2QA G3V0MrOAZsvPmCX92c0Uj2C56N/tqHrjgM6x0qQgrRkTJ+fg8g2Oj+KFqkoT4tJnf5gF /ZLhk+ieYSrrekB5uxl7fCjHlR5Suy+UXFY7Iv+YTA8nB4eLE0KQbXL5mvKNz2nWFUtN 8Z+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oxbGJHr2KscLJg3Jp7wNmlUMCtlznjqgTotwuzodnos=; b=rRJQt9c9CNJIFXiN0CaenQZJgsBtwSb+K+ZX6A90atxvRWVcqUWm+5hSABGhqm0aXu FMhjFUeeqkd3lrPq5mTFDDOR3Z8sp+Qu5OUbaKc5lnFKpQaNxAdds7+hkOkF+3bi5QNN crjirkbjVWN2AJN5EL8DcWJ/JCEL9u258i9r62aY4F7J0vg22AAaKR5e0uNs08RF4Ntv LxvHUTw4gZmfsmEEKEX98eZAE6o+GeNMvZOJluOSItnKT96ldreeODpXCz6jC3aN3Bqi 37lgYNjFpOIaLyqGyveInDujmBdXzHkcnkfdjePFJy+yjnAujYjsqvnokO02qiTAESgv YC0A== X-Gm-Message-State: AOAM533YvRfqoeE5fC41GV8mE+pUr8QRSD2XW3LuQeFTgC0Uy9lzVwnE sWFmH/Ib1EzLP231OR/vjdo= X-Received: by 2002:a17:906:17d5:: with SMTP id u21mr2039544eje.541.1612948759519; Wed, 10 Feb 2021 01:19:19 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id u2sm701801ejb.65.2021.02.10.01.19.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 01:19:18 -0800 (PST) From: Vladimir Oltean To: Jakub Kicinski , "David S. Miller" Cc: Andrew Lunn , Vivien Didelot , Florian Fainelli , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , Jiri Pirko , Ido Schimmel , Claudiu Manoil , Alexandre Belloni , UNGLinuxDriver@microchip.com, Vadym Kochan , Taras Chornyi , Grygorii Strashko , Ioana Ciornei , Ivan Vecera , linux-omap@vger.kernel.org Subject: [PATCH v3 net-next 04/11] net: dsa: configure proper brport flags when ports leave the bridge Date: Wed, 10 Feb 2021 11:14:38 +0200 Message-Id: <20210210091445.741269-5-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210210091445.741269-1-olteanv@gmail.com> References: <20210210091445.741269-1-olteanv@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vladimir Oltean For a DSA switch port operating in standalone mode, address learning doesn't make much sense since that is a bridge function. In fact, address learning even breaks setups such as this one: +---------------------------------------------+ | | | +-------------------+ | | | br0 | send receive | | +--------+-+--------+ +--------+ +--------+ | | | | | | | | | | | | | swp0 | | swp1 | | swp2 | | swp3 | | | | | | | | | | | | +-+--------+-+--------+-+--------+-+--------+-+ | ^ | ^ | | | | | +-----------+ | | | +--------------------------------+ because if the switch has a single FDB (can offload a single bridge) then source address learning on swp3 can "steal" the source MAC address of swp2 from br0's FDB, because learning frames coming from swp2 will be done twice: first on the swp1 ingress port, second on the swp3 ingress port. So the hardware FDB will become out of sync with the software bridge, and when swp2 tries to send one more packet towards swp1, the ASIC will attempt to short-circuit the forwarding path and send it directly to swp3 (since that's the last port it learned that address on), which it obviously can't, because swp3 operates in standalone mode. So DSA drivers operating in standalone mode should still configure a list of bridge port flags even when they are standalone. Currently DSA attempts to call dsa_port_bridge_flags with 0, which disables egress flooding of unknown unicast and multicast, something which doesn't make much sense. For the switches that implement .port_egress_floods - b53 and mv88e6xxx, it probably doesn't matter too much either, since they can possibly inject traffic from the CPU into a standalone port, regardless of MAC DA, even if egress flooding is turned off for that port, but certainly not all DSA switches can do that - sja1105, for example, can't. So it makes sense to use a better common default there, such as "flood everything". It should also be noted that what DSA calls "dsa_port_bridge_flags()" is a degenerate name for just calling .port_egress_floods(), since nothing else is implemented - not learning, in particular. But disabling address learning, something that this driver is also coding up for, will be supported by individual drivers once .port_egress_floods is replaced with a more generic .port_bridge_flags. Previous attempts to code up this logic have been in the common bridge layer, but as pointed out by Ido Schimmel, there are corner cases that are missed when doing that: https://patchwork.kernel.org/project/netdevbpf/patch/20210209151936.97382-5-olteanv@gmail.com/ So, at least for now, let's leave DSA in charge of setting port flags before and after the bridge join and leave. Signed-off-by: Vladimir Oltean --- Changes in v3: Patch is new, logically it was moved from the bridge layer to the DSA layer. net/dsa/port.c | 45 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 38 insertions(+), 7 deletions(-) diff --git a/net/dsa/port.c b/net/dsa/port.c index 5e079a61528e..9f65ba11ad00 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -122,6 +122,27 @@ void dsa_port_disable(struct dsa_port *dp) rtnl_unlock(); } +static void dsa_port_change_brport_flags(struct dsa_port *dp, + bool bridge_offload) +{ + unsigned long mask, flags; + int flag, err; + + mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD; + if (bridge_offload) + flags = mask; + else + flags = mask & ~BR_LEARNING; + + for_each_set_bit(flag, &mask, 32) { + err = dsa_port_pre_bridge_flags(dp, BIT(flag)); + if (err) + continue; + + dsa_port_bridge_flags(dp, flags & BIT(flag)); + } +} + int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br) { struct dsa_notifier_bridge_info info = { @@ -132,10 +153,10 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br) }; int err; - /* Set the flooding mode before joining the port in the switch */ - err = dsa_port_bridge_flags(dp, BR_FLOOD | BR_MCAST_FLOOD); - if (err) - return err; + /* Notify the port driver to set its configurable flags in a way that + * matches the initial settings of a bridge port. + */ + dsa_port_change_brport_flags(dp, true); /* Here the interface is already bridged. Reflect the current * configuration so that drivers can program their chips accordingly. @@ -146,7 +167,7 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br) /* The bridging is rolled back on error */ if (err) { - dsa_port_bridge_flags(dp, 0); + dsa_port_change_brport_flags(dp, false); dp->bridge_dev = NULL; } @@ -172,8 +193,18 @@ void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br) if (err) pr_err("DSA: failed to notify DSA_NOTIFIER_BRIDGE_LEAVE\n"); - /* Port is leaving the bridge, disable flooding */ - dsa_port_bridge_flags(dp, 0); + /* Configure the port for standalone mode (no address learning, + * flood everything). + * The bridge only emits SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS events + * when the user requests it through netlink or sysfs, but not + * automatically at port join or leave, so we need to handle resetting + * the brport flags ourselves. But we even prefer it that way, because + * otherwise, some setups might never get the notification they need, + * for example, when a port leaves a LAG that offloads the bridge, + * it becomes standalone, but as far as the bridge is concerned, no + * port ever left. + */ + dsa_port_change_brport_flags(dp, false); /* Port left the bridge, put in BR_STATE_DISABLED by the bridge layer, * so allow it to be in BR_STATE_FORWARDING to be kept functional -- 2.25.1