Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3058810rwe; Mon, 29 Aug 2022 05:16:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR4nJTsv62vRSWGObaGfnNeNeL5PLCyHMuQSS40tOoycdHcS4CeUOG+hj0fQQrALBbTzbyHG X-Received: by 2002:aa7:dc0d:0:b0:443:e1ca:bdb1 with SMTP id b13-20020aa7dc0d000000b00443e1cabdb1mr16218766edu.62.1661775407091; Mon, 29 Aug 2022 05:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661775407; cv=none; d=google.com; s=arc-20160816; b=Ro06Gjr4wcZ0rWh3HY1Nluxg9Hx114ychZhG4hLnqshAmYD4HtHEhgzPvPMJqabzbb YTRnOIGn1rbmn5ng8y0COMMeDLaomP6T9EWtLdISZ7MF1vVQ5fJxglBeovdxqw2hdSkc LoFy73dJMmZP5FUnZoGg19LUVvXyUhuYBdVxyrm33+bFf4RVjhho3/Th4KCQwLcUwfbT HES8PrR2xcmOeQauAYa3xLp6/ZP8XidWPc/62nrkt7hW/RBWt480EtvGftug3sLaCiqd XsEaTG4LLhf8x7Iko2mN5gCEbGO1OqI+oLIC4rvs3V2D8YHKKR1Bxjd5ohJ59C9NIiYk 7XSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version; bh=+RDIcXaS5jF1+5uoBIFSSk003ecVsgybqw2FzM1pilE=; b=RHkRmGPDUOcM4cAzTjcWdrKeagWnRovyX0+MbwkqHjykJts9uS6TWhjiswm13qNGx1 WiTsbhd4E2hVW+zvb8VPh4Ctdw9ta/5yddOLLsq7g5Zh+3+SvOnjOuMMqhuEzZCJV8eq B9Z4bI0rHyp8xqInroxEA031uzrJ7FYQ7oeiHiEbc+uCEqAOf4QMg1fQ++WT0//BBlPH U4J5ijjWnXrAi+11vTi2htE6ZURcB2/4k6Qc2SBUlskhm5hBoQVyst5OlbP23pa2B3yl cf9bD6cSZcfMJ+4pZlN2bAfYdi2ImU3yBDprSsRltuGfEa3M/Xu5TnBj3f2iv+e7MZjM R2eQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn23-20020a1709070d1700b007419b5feb98si1556539ejc.255.2022.08.29.05.16.19; Mon, 29 Aug 2022 05:16:47 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230308AbiH2MAs (ORCPT + 99 others); Mon, 29 Aug 2022 08:00:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229768AbiH2MA2 (ORCPT ); Mon, 29 Aug 2022 08:00:28 -0400 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69D8B72FE0; Mon, 29 Aug 2022 04:45:24 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id A21921884505; Mon, 29 Aug 2022 11:34:21 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 9954B25032B7; Mon, 29 Aug 2022 11:34:21 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 8D1D49EC0003; Mon, 29 Aug 2022 11:34:21 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Mon, 29 Aug 2022 13:34:21 +0200 From: netdev@kapio-technology.com To: Ido Schimmel Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , UNGLinuxDriver@microchip.com, Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Christian Marangi , Daniel Borkmann , Yuwei Wang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 net-next 1/6] net: bridge: add locked entry fdb flag to extend locked port feature In-Reply-To: References: <20220826114538.705433-1-netdev@kapio-technology.com> <20220826114538.705433-2-netdev@kapio-technology.com> User-Agent: Gigahost Webmail Message-ID: X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-08-27 17:19, Ido Schimmel wrote: > > How about the below (untested): > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > index 68b3e850bcb9..9143a94a1c57 100644 > --- a/net/bridge/br_input.c > +++ b/net/bridge/br_input.c > @@ -109,9 +109,18 @@ int br_handle_frame_finish(struct net *net, > struct sock *sk, struct sk_buff *skb > struct net_bridge_fdb_entry *fdb_src = > br_fdb_find_rcu(br, eth_hdr(skb)->h_source, > vid); > > - if (!fdb_src || READ_ONCE(fdb_src->dst) != p || > - test_bit(BR_FDB_LOCAL, &fdb_src->flags)) > + if (!fdb_src) { > + if (p->flags & BR_PORT_MAB) { > + __set_bit(BR_FDB_ENTRY_LOCKED, &flags); > + br_fdb_update(br, p, > eth_hdr(skb)->h_source, > + vid, flags); > + } > + goto drop; > + } else if (READ_ONCE(fdb_src->dst) != p || > + test_bit(BR_FDB_LOCAL, &fdb_src->flags) || > + test_bit(BR_FDB_LOCKED, &fdb_src->flags)) { > goto drop; > + } > } > > The semantics are very clear, IMO. On FDB miss, add a locked FDB entry > and drop the packet. On FDB mismatch, drop the packet. > > Entry can roam from an unauthorized port to an authorized port, but not > the other way around. Not sure what is the use case for allowing > roaming > between unauthorized ports. > > Note that with the above, locked entries are not refreshed and will > therefore age out unless replaced by user space. > Okay, I got the semantics (locked/unlocked vs unauthorized/authorized) reversed, so I will go with your suggestion.