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
| ||
|
Date: Sat, 13 Feb 2016 16:48:35 -0500 From: Vivien Didelot <vivien.didelot@...oirfairelinux.com> To: Ido Schimmel <idosch@...lanox.com> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...oirfairelinux.com, "David S. Miller" <davem@...emloft.net>, Jiri Pirko <jiri@...nulli.us>, Scott Feldman <sfeldma@...il.com>, Nikolay Aleksandrov <nikolay@...ulusnetworks.com>, Stephen Hemminger <stephen@...workplumber.org>, Florian Fainelli <f.fainelli@...il.com>, Andrew Lunn <andrew@...n.ch> Subject: Re: [PATCH RFC 2/3] net: bridge: set forwarding state on port removal Hi Ido, Ido Schimmel <idosch@...lanox.com> writes: > Fri, Feb 12, 2016 at 11:34:19PM IST, vivien.didelot@...oirfairelinux.com wrote: > > Hi Vivien, > >>When a port leaves a bridge, the bridge layer puts its STP state to >>Disabled. If the port is part of an hardware switch, the mode needs to >>be set to Forwarding in order to restore communication with the CPU. >> >>Call br_set_state() in del_nbp(), which only affects switchdev users. >> >>Signed-off-by: Vivien Didelot <vivien.didelot@...oirfairelinux.com> >>--- > > If you have a LAG device in the bridge and one of the ports leaves the > LAG, then the bridge's teardown sequence isn't invoked and you need to > do the cleanup yourself, by calling your dsa_slave_bridge_port_leave() > function (just an example, I know you don't currently support this). > > With this change, you'll have to call both the > dsa_slave_bridge_port_leave() function and dsa_slave_stp_update() > instead of always calling the same one when leaving a bridge. > > Also, I think this kind of things should be done by drivers, as it's > specific to them. For example, in the case of a physical port, this > wouldn't benefit mlxsw at all, as STP state is a per-VLAN setting and > since VLANs were already flushed in nbp_vlan_flush(), then nothing would > happen. Thanks for the explanation! I drop this RFC then. Best, -v
Powered by blists - more mailing lists