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 722DCC43334 for ; Wed, 6 Jul 2022 14:23:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233075AbiGFOXl (ORCPT ); Wed, 6 Jul 2022 10:23:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230420AbiGFOXj (ORCPT ); Wed, 6 Jul 2022 10:23:39 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3E6C21A7; Wed, 6 Jul 2022 07:23:37 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id f2so16941595wrr.6; Wed, 06 Jul 2022 07:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WPpPFt2vreAvukEchuJ8KcyDhd0FY1gp7qevaVZJpHI=; b=MipxUNNv1CuzDomW4TDLl1zhaylRYTrx3HZq9GYsjxdcB9+8zSPYgqHTdiwr1z+vMx 1FrXYtgFdTKQJAw332y5OtL+a1DSibzdekPFpU8scZF5wsXT5IozNxflL5z/F9J/EOc8 6fUUAb+3A0iOvdHXB3B0v7vb03sGXtWPoywgxAYh5fGJNL2Gf/akgZZ3o5Q2t/X8AhTv oGRsf1z5hI6JAZutJvqwANARqRbZmUNjWEgtE6le0ja1+VhmfDcpIbt7w6NmofsaRELe 4kHBuQJNq9n9YQUGsOMl/wOhnMFV9A/p892T0cj4Bxeo7uwyANFpUYfIfrchPmUhtkUp n2Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WPpPFt2vreAvukEchuJ8KcyDhd0FY1gp7qevaVZJpHI=; b=LBHHB0ohVYLuqsHu7iV26RaERXR4L4u4RGSgB2CGW/WeUB/Uz9BCtxwX1RUMTCIw/T yOR0mm/9iMfQ3muhp7y5YZ2C+qSdQdvixJnF/dPr8VZo5yKpIIZHImPNqqzQOmlOUkaR 7aMfZEEyk/+tMRqSZ19l0brOdwoODOSVUyteEDxPCXW7xfY/tJNwaXLwrwUtOJeBz56N xu+wAqPp7aefBhmCjHSY7DYakR2uIh+B0Aea2/YQNFCSoAqeXj+o0cvwzP4hFIDLTHFA 7zrh42WlXE0RDC/PmK6+plaBHcSY8VFN6PjafOjKmkcxpGypp7KdND0xIuLnXZvK13RZ NsPQ== X-Gm-Message-State: AJIora8Zcqwi3t2CGBqtimr/51MXR5RsUkcVR6VIrQy5dfBfR3nD48/2 1kIE3lAECQD6mM5x9FOzU/d834rns2/K6+oooJQ= X-Google-Smtp-Source: AGRyM1vyCqZB5Fa3OerranrlSzgeG9k7CwyXwEFfqtrJ8m53fLEj0coZuzcxmy+5Zyo17nvKGoYAEoROlUXUwRhXr1Q= X-Received: by 2002:a5d:4304:0:b0:21b:9b2c:be34 with SMTP id h4-20020a5d4304000000b0021b9b2cbe34mr40056150wrq.577.1657117416326; Wed, 06 Jul 2022 07:23:36 -0700 (PDT) MIME-Version: 1.0 References: <20220524152144.40527-1-schultz.hans+netdev@gmail.com> <20220524152144.40527-4-schultz.hans+netdev@gmail.com> <20220627180557.xnxud7d6ol22lexb@skbuf> <20220706085559.oyvzijcikivemfkg@skbuf> In-Reply-To: From: Hans S Date: Wed, 6 Jul 2022 16:23:25 +0200 Message-ID: Subject: Re: [PATCH V3 net-next 3/4] net: dsa: mv88e6xxx: mac-auth/MAB implementation To: Vladimir Oltean Cc: "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, Hans Schultz , Andrew Lunn , Vivien Didelot , Florian Fainelli , Eric Dumazet , Paolo Abeni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Daniel Borkmann , Ido Schimmel , linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >> @@ -919,6 +920,9 @@ static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port, > >> if (err) > >> dev_err(chip->dev, > >> "p%d: failed to force MAC link down\n", port); > >> + else > >> + if (mv88e6xxx_port_is_locked(chip, port, true)) > >> + mv88e6xxx_atu_locked_entry_flush(ds, port); > > > >This is superfluous, is it not? The bridge will transition a port whose > >link goes down to BR_STATE_DISABLED, which will make dsa_port_set_state() > >fast-age the dynamic FDB entries on the port, which you've already > >handled below. > > I removed this code, but then on link down the locked entries were not > cleared out. Something not as thought? I don't see a fast ageing happening on link down. There is the two cases: 1. Soft link down With iproute2 command the link is brought down and mv88e6xxx_mac_link_down() is called with rtnl lock taken. 2. Hard link down I remove the cable from the port and mv88e6xxx_mac_link_down() is called without rtnl lock. As the hard link down case calls without rtnl lock, either I trigger the case you have mentioned or I have to use rtnl_is_locked() somewhere along the line? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EC92540AE8 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2F4E24012D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WPpPFt2vreAvukEchuJ8KcyDhd0FY1gp7qevaVZJpHI=; b=MipxUNNv1CuzDomW4TDLl1zhaylRYTrx3HZq9GYsjxdcB9+8zSPYgqHTdiwr1z+vMx 1FrXYtgFdTKQJAw332y5OtL+a1DSibzdekPFpU8scZF5wsXT5IozNxflL5z/F9J/EOc8 6fUUAb+3A0iOvdHXB3B0v7vb03sGXtWPoywgxAYh5fGJNL2Gf/akgZZ3o5Q2t/X8AhTv oGRsf1z5hI6JAZutJvqwANARqRbZmUNjWEgtE6le0ja1+VhmfDcpIbt7w6NmofsaRELe 4kHBuQJNq9n9YQUGsOMl/wOhnMFV9A/p892T0cj4Bxeo7uwyANFpUYfIfrchPmUhtkUp n2Rw== MIME-Version: 1.0 References: <20220524152144.40527-1-schultz.hans+netdev@gmail.com> <20220524152144.40527-4-schultz.hans+netdev@gmail.com> <20220627180557.xnxud7d6ol22lexb@skbuf> <20220706085559.oyvzijcikivemfkg@skbuf> In-Reply-To: From: Hans S Date: Wed, 6 Jul 2022 16:23:25 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Bridge] [PATCH V3 net-next 3/4] net: dsa: mv88e6xxx: mac-auth/MAB implementation List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Oltean Cc: Ivan Vecera , Andrew Lunn , Florian Fainelli , Jiri Pirko , Daniel Borkmann , netdev@vger.kernel.org, Nikolay Aleksandrov , bridge@lists.linux-foundation.org, Eric Dumazet , Ido Schimmel , Vivien Didelot , Hans Schultz , linux-kselftest@vger.kernel.org, Roopa Prabhu , Jakub Kicinski , Paolo Abeni , Shuah Khan , "David S. Miller" , linux-kernel@vger.kernel.org > >> @@ -919,6 +920,9 @@ static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port, > >> if (err) > >> dev_err(chip->dev, > >> "p%d: failed to force MAC link down\n", port); > >> + else > >> + if (mv88e6xxx_port_is_locked(chip, port, true)) > >> + mv88e6xxx_atu_locked_entry_flush(ds, port); > > > >This is superfluous, is it not? The bridge will transition a port whose > >link goes down to BR_STATE_DISABLED, which will make dsa_port_set_state() > >fast-age the dynamic FDB entries on the port, which you've already > >handled below. > > I removed this code, but then on link down the locked entries were not > cleared out. Something not as thought? I don't see a fast ageing happening on link down. There is the two cases: 1. Soft link down With iproute2 command the link is brought down and mv88e6xxx_mac_link_down() is called with rtnl lock taken. 2. Hard link down I remove the cable from the port and mv88e6xxx_mac_link_down() is called without rtnl lock. As the hard link down case calls without rtnl lock, either I trigger the case you have mentioned or I have to use rtnl_is_locked() somewhere along the line?