From: Hans Schultz <schultz.hans@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>,
Hans Schultz <schultz.hans@gmail.com>
Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Vivien Didelot <vivien.didelot@gmail.com>,
Ido Schimmel <idosch@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>,
kuba@kernel.org, davem@davemloft.net
Subject: Re: [Bridge] [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation
Date: Tue, 22 Mar 2022 14:21:58 +0100 [thread overview]
Message-ID: <86ee2ujf61.fsf@gmail.com> (raw)
In-Reply-To: <20220322110806.kbdb362jf6pbtqaf@skbuf>
On tis, mar 22, 2022 at 13:08, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Tue, Mar 22, 2022 at 12:01:13PM +0100, Hans Schultz wrote:
>> On fre, mar 18, 2022 at 15:19, Vladimir Oltean <olteanv@gmail.com> wrote:
>> > On Fri, Mar 18, 2022 at 02:10:26PM +0100, Hans Schultz wrote:
>> >> In the offloaded case there is no difference between static and dynamic
>> >> flags, which I see as a general issue. (The resulting ATU entry is static
>> >> in either case.)
>> >
>> > It _is_ a problem. We had the same problem with the is_local bit.
>> > Independently of this series, you can add the dynamic bit to struct
>> > switchdev_notifier_fdb_info and make drivers reject it.
>> >
>> >> These FDB entries are removed when link goes down (soft or hard). The
>> >> zero DPV entries that the new code introduces age out after 5 minutes,
>> >> while the locked flagged FDB entries are removed by link down (thus the
>> >> FDB and the ATU are not in sync in this case).
>> >
>> > Ok, so don't let them disappear from hardware, refresh them from the
>> > driver, since user space and the bridge driver expect that they are
>> > still there.
>>
>> I have now tested with two extra unmanaged switches (each connected to a
>> seperate port on our managed switch, and when migrating from one port to
>> another, there is member violations, but as the initial entry ages out,
>> a new miss violation occurs and the new port adds the locked entry. In
>> this case I only see one locked entry, either on the initial port or
>> later on the port the host migrated to (via switch).
>>
>> If I refresh the ATU entries indefinitly, then this migration will for
>> sure not work, and with the member violation suppressed, it will be
>> silent about it.
>
> Manual says that migrations should trigger miss violations if configured
> adequately, is this not the case?
>
Yes, but that depends on the ATU entries ageing out. As it is now, it works.
>> So I don't think it is a good idea to refresh the ATU entries
>> indefinitely.
>>
>> Another issue I see, is that there is a deadlock or similar issue when
>> receiving violations and running 'bridge fdb show' (it seemed that
>> member violations also caused this, but not sure yet...), as the unit
>> freezes, not to return...
>
> Have you enabled lockdep, debug atomic sleep, detect hung tasks, things
> like that?
No, I haven't looked deeper into it yet. Maybe I was hoping someone had
an idea... but I guess it cannot be a netlink deadlock?
WARNING: multiple messages have this Message-ID (diff)
From: Hans Schultz <schultz.hans@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>,
Hans Schultz <schultz.hans@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>, Ivan Vecera <ivecera@redhat.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Ido Schimmel <idosch@nvidia.com>,
linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation
Date: Tue, 22 Mar 2022 14:21:58 +0100 [thread overview]
Message-ID: <86ee2ujf61.fsf@gmail.com> (raw)
In-Reply-To: <20220322110806.kbdb362jf6pbtqaf@skbuf>
On tis, mar 22, 2022 at 13:08, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Tue, Mar 22, 2022 at 12:01:13PM +0100, Hans Schultz wrote:
>> On fre, mar 18, 2022 at 15:19, Vladimir Oltean <olteanv@gmail.com> wrote:
>> > On Fri, Mar 18, 2022 at 02:10:26PM +0100, Hans Schultz wrote:
>> >> In the offloaded case there is no difference between static and dynamic
>> >> flags, which I see as a general issue. (The resulting ATU entry is static
>> >> in either case.)
>> >
>> > It _is_ a problem. We had the same problem with the is_local bit.
>> > Independently of this series, you can add the dynamic bit to struct
>> > switchdev_notifier_fdb_info and make drivers reject it.
>> >
>> >> These FDB entries are removed when link goes down (soft or hard). The
>> >> zero DPV entries that the new code introduces age out after 5 minutes,
>> >> while the locked flagged FDB entries are removed by link down (thus the
>> >> FDB and the ATU are not in sync in this case).
>> >
>> > Ok, so don't let them disappear from hardware, refresh them from the
>> > driver, since user space and the bridge driver expect that they are
>> > still there.
>>
>> I have now tested with two extra unmanaged switches (each connected to a
>> seperate port on our managed switch, and when migrating from one port to
>> another, there is member violations, but as the initial entry ages out,
>> a new miss violation occurs and the new port adds the locked entry. In
>> this case I only see one locked entry, either on the initial port or
>> later on the port the host migrated to (via switch).
>>
>> If I refresh the ATU entries indefinitly, then this migration will for
>> sure not work, and with the member violation suppressed, it will be
>> silent about it.
>
> Manual says that migrations should trigger miss violations if configured
> adequately, is this not the case?
>
Yes, but that depends on the ATU entries ageing out. As it is now, it works.
>> So I don't think it is a good idea to refresh the ATU entries
>> indefinitely.
>>
>> Another issue I see, is that there is a deadlock or similar issue when
>> receiving violations and running 'bridge fdb show' (it seemed that
>> member violations also caused this, but not sure yet...), as the unit
>> freezes, not to return...
>
> Have you enabled lockdep, debug atomic sleep, detect hung tasks, things
> like that?
No, I haven't looked deeper into it yet. Maybe I was hoping someone had
an idea... but I guess it cannot be a netlink deadlock?
next prev parent reply other threads:[~2022-03-22 13:21 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 14:23 [Bridge] [PATCH net-next 0/3] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans Schultz
2022-03-10 14:23 ` Hans Schultz
2022-03-10 14:23 ` [Bridge] [PATCH net-next 1/3] net: bridge: add fdb flag to extent locked port feature Hans Schultz
2022-03-10 14:23 ` Hans Schultz
2022-03-10 14:42 ` [Bridge] " Nikolay Aleksandrov
2022-03-10 14:42 ` Nikolay Aleksandrov
2022-03-10 15:38 ` [Bridge] " Hans Schultz
2022-03-10 15:38 ` Hans Schultz
2022-03-10 15:57 ` [Bridge] " Nikolay Aleksandrov
2022-03-10 15:57 ` Nikolay Aleksandrov
2022-03-10 16:11 ` [Bridge] " Hans Schultz
2022-03-10 16:11 ` Hans Schultz
2022-03-10 16:14 ` [Bridge] " Nikolay Aleksandrov
2022-03-10 16:14 ` Nikolay Aleksandrov
2022-03-10 16:33 ` [Bridge] " Hans Schultz
2022-03-10 16:33 ` Hans Schultz
2022-03-14 15:30 ` [Bridge] " Ido Schimmel
2022-03-14 15:30 ` Ido Schimmel
2022-03-15 8:48 ` [Bridge] " Hans Schultz
2022-03-15 8:48 ` Hans Schultz
2022-03-15 11:00 ` [Bridge] " Ido Schimmel
2022-03-15 11:00 ` Ido Schimmel
2022-03-10 14:23 ` [Bridge] [PATCH net-next 2/3] net: switchdev: add support for offloading of fdb locked flag Hans Schultz
2022-03-10 14:23 ` Hans Schultz
2022-03-10 14:23 ` [Bridge] [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans Schultz
2022-03-10 14:23 ` Hans Schultz
2022-03-10 14:28 ` [Bridge] " Vladimir Oltean
2022-03-10 14:28 ` Vladimir Oltean
2022-03-10 15:00 ` [Bridge] " Hans Schultz
2022-03-10 15:00 ` Hans Schultz
2022-03-10 15:07 ` [Bridge] " Vladimir Oltean
2022-03-10 15:07 ` Vladimir Oltean
2022-03-10 15:51 ` [Bridge] " Hans Schultz
2022-03-10 15:51 ` Hans Schultz
2022-03-10 16:05 ` [Bridge] " Vladimir Oltean
2022-03-10 16:05 ` Vladimir Oltean
2022-03-10 16:40 ` [Bridge] " Hans Schultz
2022-03-10 16:40 ` Hans Schultz
2022-03-10 15:57 ` [Bridge] " Hans Schultz
2022-03-10 15:57 ` Hans Schultz
2022-03-14 10:46 ` [Bridge] " Hans Schultz
2022-03-14 10:46 ` Hans Schultz
2022-03-16 23:34 ` [Bridge] " Vladimir Oltean
2022-03-16 23:34 ` Vladimir Oltean
2022-03-17 8:52 ` [Bridge] " Hans Schultz
2022-03-17 8:52 ` Hans Schultz
2022-03-17 14:19 ` [Bridge] " Andrew Lunn
2022-03-17 14:19 ` Andrew Lunn
2022-03-17 15:36 ` [Bridge] " Vladimir Oltean
2022-03-17 15:36 ` Vladimir Oltean
2022-03-17 16:07 ` [Bridge] " Hans Schultz
2022-03-17 16:07 ` Hans Schultz
2022-03-17 16:18 ` [Bridge] " Vladimir Oltean
2022-03-17 16:18 ` Vladimir Oltean
2022-03-17 16:58 ` [Bridge] " Hans Schultz
2022-03-17 16:58 ` Hans Schultz
2022-03-17 17:20 ` [Bridge] " Vladimir Oltean
2022-03-17 17:20 ` Vladimir Oltean
2022-03-18 10:04 ` [Bridge] " Hans Schultz
2022-03-18 10:04 ` Hans Schultz
2022-03-18 12:14 ` [Bridge] " Vladimir Oltean
2022-03-18 12:14 ` Vladimir Oltean
2022-03-18 13:10 ` [Bridge] " Hans Schultz
2022-03-18 13:10 ` Hans Schultz
2022-03-18 13:19 ` [Bridge] " Vladimir Oltean
2022-03-18 13:19 ` Vladimir Oltean
2022-03-22 11:01 ` [Bridge] " Hans Schultz
2022-03-22 11:01 ` Hans Schultz
2022-03-22 11:08 ` [Bridge] " Vladimir Oltean
2022-03-22 11:08 ` Vladimir Oltean
2022-03-22 13:21 ` Hans Schultz [this message]
2022-03-22 13:21 ` Hans Schultz
2022-03-22 14:47 ` [Bridge] " Hans Schultz
2022-03-22 14:47 ` Hans Schultz
2022-03-23 10:13 ` [Bridge] " Hans Schultz
2022-03-23 10:13 ` Hans Schultz
2022-03-23 10:16 ` [Bridge] " Vladimir Oltean
2022-03-23 10:16 ` Vladimir Oltean
2022-03-23 10:46 ` [Bridge] " Hans Schultz
2022-03-23 10:46 ` Hans Schultz
2022-03-23 10:57 ` [Bridge] " Hans Schultz
2022-03-23 10:57 ` Hans Schultz
2022-03-23 11:21 ` [Bridge] " Vladimir Oltean
2022-03-23 11:21 ` Vladimir Oltean
2022-03-23 11:43 ` [Bridge] " Hans Schultz
2022-03-23 11:43 ` Hans Schultz
2022-03-23 11:54 ` [Bridge] " Vladimir Oltean
2022-03-23 11:54 ` Vladimir Oltean
2022-03-21 14:51 ` [Bridge] " Hans Schultz
2022-03-21 14:51 ` Hans Schultz
2022-03-10 14:54 ` [Bridge] " Andrew Lunn
2022-03-10 14:54 ` Andrew Lunn
2022-03-11 7:59 ` [Bridge] " Hans Schultz
2022-03-11 7:59 ` Hans Schultz
2022-03-14 15:50 ` [Bridge] [PATCH net-next 0/3] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Ido Schimmel
2022-03-14 15:50 ` Ido Schimmel
2022-03-15 8:59 ` [Bridge] " Hans Schultz
2022-03-15 8:59 ` Hans Schultz
2022-03-15 11:11 ` [Bridge] " Ido Schimmel
2022-03-15 11:11 ` Ido Schimmel
2022-03-17 0:18 ` [Bridge] " Florian Fainelli
2022-03-17 0:18 ` Florian Fainelli
2022-03-17 8:29 ` [Bridge] " Hans Schultz
2022-03-17 8:29 ` Hans Schultz
2022-03-17 18:42 ` [Bridge] " Vladimir Oltean
2022-03-17 18:42 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ee2ujf61.fsf@gmail.com \
--to=schultz.hans@gmail.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@nvidia.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.