netdev - Re: [PATCH v3 net-next 10/24] net: dsa: Unset vlan

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: <20190413151152.GB17901@lunn.ch>
Date:   Sat, 13 Apr 2019 17:11:52 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     f.fainelli@...il.com, vivien.didelot@...il.com,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, georg.waibel@...sor-technik.de
Subject: Re: [PATCH v3 net-next 10/24] net: dsa: Unset vlan_filtering when
 ports leave the bridge

On Sat, Apr 13, 2019 at 04:28:08AM +0300, Vladimir Oltean wrote:
> When ports are standalone (after they left the bridge), they should have
> no VLAN filtering semantics (they should pass all traffic to the CPU).
> Currently this is not true for switchdev drivers, because the bridge
> "forgets" to unset that.
> 
> Normally one would think that doing this at the bridge layer would be a
> better idea, i.e. call br_vlan_filter_toggle() from br_del_if(), similar
> to how nbp_vlan_init() is called from br_add_if().
> 
> However what complicates that approach, and makes this one preferable,
> is the fact that for the bridge core, vlan_filtering is a per-bridge
> setting, whereas for switchdev/DSA it is per-port. Also there are
> switches where the setting is per the entire device, and unsetting
> vlan_filtering one by one, for each leaving port, would not be possible
> from the bridge core without a certain level of awareness. So do this in
> DSA and let drivers be unaware of it.
> 
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew