netdev - Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201108235939.GC1417181@lunn.ch>
Date:   Mon, 9 Nov 2020 00:59:39 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Marek Behun <marek.behun@....cz>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: listen for
 SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

On Sun, Nov 08, 2020 at 07:23:55PM +0200, Vladimir Oltean wrote:
> On Sun, Nov 08, 2020 at 10:09:25PM +0800, DENG Qingfang wrote:
> > Can it be turned off for switches that support SA learning from CPU?
> 
> Is there a good reason I would add another property per switch and not
> just do it unconditionally?

Just throwing out ideas, i've no idea if they are relevant. I wonder
if we can get into issues with fast ageing with a topology change?  We
don't have too much control over the hardware. I think some devices
just flush everything, or maybe just one port. So we have different
life times for CPU port database entries and user port database
entries?

We might also run into bugs with flushing removing static database
entries which should not be. But that would be a bug. Also, dumping
the database might run into bugs since we have not had entries for the
CPU port before.

We also need to make sure the static entries get removed correctly
when a host moves. The mv88e6xxx will not replace a static entry with
a dynamically learned one. It will probably rise an ATU violation
interrupt that frames have come in the wrong port.

What about switches which do not implement port_fdb_add? Do these
patches at least do something sensible?

	Andrew