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;
Date:   Mon, 29 Aug 2022 17:37:27 +0300
From:   Ido Schimmel <idosch@nvidia.com>
To:     netdev@kapio-technology.com
Cc:     davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
        Florian Fainelli <f.fainelli@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Hauke Mehrtens <hauke@hauke-m.de>,
        Woojung Huh <woojung.huh@microchip.com>,
        UNGLinuxDriver@microchip.com, Sean Wang <sean.wang@mediatek.com>,
        Landen Chao <Landen.Chao@mediatek.com>,
        DENG Qingfang <dqfext@gmail.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Ivan Vecera <ivecera@redhat.com>,
        Roopa Prabhu <roopa@nvidia.com>,
        Nikolay Aleksandrov <razor@blackwall.org>,
        Shuah Khan <shuah@kernel.org>,
        Christian Marangi <ansuelsmth@gmail.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Yuwei Wang <wangyuweihx@gmail.com>,
        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 6/6] selftests: forwarding: add test of
 MAC-Auth Bypass to locked port tests
Message-ID: <YwzPJ2oCYJQHOsXD@shredder>
References: <20220826114538.705433-1-netdev@kapio-technology.com>
 <20220826114538.705433-7-netdev@kapio-technology.com>
 <YwpgvkojEdytzCAB@shredder>
 <7654860e4d7d43c15d482c6caeb6a773@kapio-technology.com>
 <YwxtVhlPjq+M9QMY@shredder>
 <2967ccc234bb672f5440a4b175b73768@kapio-technology.com>
 <Ywyj1VF1wlYqlHb6@shredder>
 <9e1a9eb218bbaa0d36cb98ff5d4b97d7@kapio-technology.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9e1a9eb218bbaa0d36cb98ff5d4b97d7@kapio-technology.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2m2rb9+Hht07reOtEB3sOo6JZDubAcYQcjGKalGmdUKkqZ7aGBmuQNlsK3lx?=
 =?us-ascii?Q?ezycNrFNQ1CUMl8p/gLFF4dH6jecDotzNc7joq9oSuW3lXDILL1+CJRRnpJg?=
 =?us-ascii?Q?I4rRGqnySQWScV/MlQGXgkwIRocDgHT29lBnu8s+NRcLsTF73CPqkq0M4a8q?=
 =?us-ascii?Q?355Pom1mu/EYZkVvaE7rESXdcKzatufAOAz1cN6msAHXQPWSlDav0G12o7Fd?=
 =?us-ascii?Q?mJuKvXsphgoUp/Qag7yFZKRxVGn1tWjmpXI3JOG9XlhKrWTtKk3/4yQFzJP4?=
 =?us-ascii?Q?2lFQpTQIaxPXulZsMNyPFzQ42FFpQYjVvKGONfRFTJkfUNjOMNsuSk4tr6Wx?=
 =?us-ascii?Q?Ebbdv8oxQLi/mRD7mv3zzs4HBeh988Je+6dspWsr2GY0NIkPeOL2VnqXzQ++?=
 =?us-ascii?Q?Wn8SwuUy9NUj25SygUVznp5O8ez7Eq7zopSEDmj4q0lnNY6rVQ9R5ktXkSmx?=
 =?us-ascii?Q?5+zRG7SerPobyTvhdAwym3MVNdwtBIyxHpDpKPNc42ArzeSMuiqFlcOkfUuE?=
 =?us-ascii?Q?qt+23XWxufJTWazx2e/0rUu+HfMyksy+hr1ZxPh7SCdlaLHUzalPEPwoQvoB?=
 =?us-ascii?Q?1jJ1FPbBNZehPLapbdUxmzQk2LpU4OFZQjCyIrCNQXJj8dkGEfFQeDOWhhup?=
 =?us-ascii?Q?gvFHySmyfwcMsNsPn2XZ3fhrVenHmvQ0FnFBpFUudn0CB+j97qb267l0i2ij?=
 =?us-ascii?Q?SEt7LVNZ6O3YHwPjDFu3nFeGObJlTzRFGv3bFM+iQ8lKKaDbuprqXeZs1ros?=
 =?us-ascii?Q?mdUBA99j2Wo9dCxT49GNtsi+LVPeTKk9CIAT5FXU/P4cstpgaAATWdQolHyz?=
 =?us-ascii?Q?87zMoL7ln/ej3U+1DYRXTMQI51B+NORp/mzUbDUy3CyGCXGAdcwNEIGTyIq/?=
 =?us-ascii?Q?p3MHgmHRsInLMk9l+NSKC5SMxUy4H/0KQJtm6f74cTorBDcbpMEWNzA8A3jO?=
 =?us-ascii?Q?J3ZNEXLWomyvBC1jSf0jFcGhR7NUlY89T+mCi4Xfsd3hHu+6km2a7I5drwKe?=
 =?us-ascii?Q?tVmHRzDICqJVCp1YMFx5DCEEo11yT30mAuAn0BBb8UycOm9JbTZuZr+ULY98?=
 =?us-ascii?Q?yhuw3QgAI0ntNVGlSyEWwm3kt3CYcLaLGbAl5fqIA1x2uYn/da+1TgrFAvTQ?=
 =?us-ascii?Q?h7PO5xXqcyc22RrIpSrITbWz9VuvJSddR0cT563p5go++FEeSYDJXhthH4Xa?=
 =?us-ascii?Q?oNOyM9lWViqS+1YrKV7DIRkZFimhxYv6sIDrzUEQJt9vZJ2pVhdrcUeSUhF8?=
 =?us-ascii?Q?C+yunzMoEWZe2J/3KrsNugiITO2YDlrA/xVUdYog8SdTf1EgLvHgbnlppHLm?=
 =?us-ascii?Q?mq7qlyiKvz7bBGtvUAIt0HWkuKmlsx1Ftg1A50AAfzVt22N9xaqSmzAZPAVa?=
 =?us-ascii?Q?/RfnzWngB2czh5FGC+lNenU+QnZdFrRKjWEKNkUcy1x3HNlc0FaTDb0QWIq2?=
 =?us-ascii?Q?p8dOrBPOmS7VjJwCZkXMgdp7TwIyjWQtM7jHt7nT56m+G4/tY8J44mvYSPXy?=
 =?us-ascii?Q?p5CEIW5AnaHAuFu2IQrpgXyIlAxi6AzazXQiabWmCJUf/22MB5STtcBrzmF5?=
 =?us-ascii?Q?lFFKXsc+5d4IB/Ve1g7wUMGlccjSsDA8CeS43w/h?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b10561f2-253b-486e-bc76-08da89cc0237
X-MS-Exchange-CrossTenant-AuthSource: PH7SPRMB0001.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2022 14:37:33.1137
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JJ0L7O1tTrrj77INHxE1e20LUM9123ryNZQX6FCCXYvd34KQgRWp3hSQSy5KAqSKKZsNiaJGCTtLtPNx0wuh6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2752
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 29, 2022 at 02:04:42PM +0200, netdev@kapio-technology.com wrote:
> On 2022-08-29 13:32, Ido Schimmel wrote:
> > > The final decision on this rests with you I would say.
> > 
> > If the requirement for this feature (with or without MAB) is to work
> > with dynamic entries (which is not what is currently implemented in the
> > selftests), then learning needs to be enabled for the sole reason of
> > refreshing the dynamic entries added by user space. That is, updating
> > 'fdb->updated' with current jiffies value.
> > 
> > So, is this the requirement? I checked the hostapd fork you posted some
> > time ago and I get the impression that the answer is yes [1], but I want
> > to verify I'm not missing something.
> > 
> > [1] https://github.com/westermo/hostapd/commit/95dc96f9e89131b2319f5eae8ae7ac99868b7cd0#diff-338b6fad34b4bdb015d7d96930974bd96796b754257473b6c91527789656d6edR11
> > 
> > 
> 
> I cannot say that it is a requirement with respect to the bridge
> implementation, but it is with the driver implementation. But you are right
> that it is to be used with dynamic entries.

OK, so it's a requirement for both since we need both data paths to act
the same.

[...]

> Port association is needed for MAB to work at all on mv88e6xxx, but for
> 802.1X port association is only needed for dynamic ATU entries.

Ageing of dynamic entries in the bridge requires learning to be on as
well, but in these test cases you are only using static entries and
there is no reason to enable learning in the bridge for that. I prefer
not to leak this mv88e6xxx implementation detail to user space and
instead have the driver enable port association based on whether
"learning" or "mab" is on.

[...]

> Oh yes, I meant in the iproute2 accompanying patch set to this one?

You can send it as a standalone patch to iproute2-next:
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git

Subject prefix should be "[PATCH iproute2-next]". See this commit for
reference:
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=d2eecb9d1d4823a04431debd990824a5d610bfcf