netdev - [PATCH net-next 00/13] Improvements to DSA core VLAN manipulation

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 28 Apr 2019 21:45:41 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     f.fainelli@...il.com, vivien.didelot@...il.com, andrew@...n.ch,
        davem@...emloft.net
Cc:     netdev@...r.kernel.org, Vladimir Oltean <olteanv@...il.com>
Subject: [PATCH net-next 00/13] Improvements to DSA core VLAN manipulation

In preparation of submitting the NXP SJA1105 driver, the Broadcom b53
and Mediatek mt7530 drivers have been found to apply some VLAN
workarounds that are needed in the new driver as well.

Therefore this patchset is mostly simply promoting the DSA driver
workarounds for VLAN to the generic code.

The b53 driver was applying a few workarounds in order to convince DSA
that its vlan_filtering setting is not really per-port. This is now
simply set by the driver via a DSA variable at probe time. The sja1105
driver will be a second user of this.

The mt7530 was also keeping track of when the .port_vlan_filtering
callback was being called. Remove the kept state from this driver
and simplify dealing with vlan_filtering in the generic case.

TODO:

Find the best way to deal generically with the situation described below
(discussion at https://lkml.org/lkml/2019/4/16/1355):

> > +Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but
> > +all bridges should have the same level of VLAN awareness (either both have
> > +``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact
> > +that VLAN awareness is global at the switch level is that once a bridge with
> > +``vlan_filtering`` enslaves at least one switch port, the other un-bridged
> > +ports are no longer available for standalone traffic termination.
> 
> That is quite a limitation that I don't think I had fully grasped until
> reading your different patches. Since enslaving ports into a bridge
> comes after the network device was already made available for use, maybe
> you should force the carrier down or something along those lines as soon
> as a port is enslaved into a bridge with vlan_filtering=1 to make this
> more predictable for the user?

Vladimir Oltean (13):
  net: dsa: Fix pharse -> phase typo
  net: dsa: Store vlan_filtering as a property of dsa_port
  net: dsa: Be aware of switches where VLAN filtering is a global
    setting
  net: dsa: b53: Let DSA handle mismatched VLAN filtering settings
  net: dsa: Unset vlan_filtering when ports leave the bridge
  net: dsa: mt7530: Let DSA handle the unsetting of vlan_filtering
  net: dsa: Keep the vlan_filtering setting in dsa_switch if it's global
  net: dsa: Add helper function to retrieve VLAN awareness setting
  net: dsa: mt7530: Use the DSA vlan_filtering helper function
  net: dsa: Skip calling .port_vlan_filtering on no change
  net: dsa: b53: Let DSA call .port_vlan_filtering only when necessary
  net: dsa: b53: Use vlan_filtering property from dsa_switch
  net: dsa: Add more convenient functions for installing port VLANs

 drivers/net/dsa/b53/b53_common.c | 34 +++++--------
 drivers/net/dsa/b53/b53_priv.h   |  1 -
 drivers/net/dsa/mt7530.c         | 20 +++-----
 drivers/net/dsa/mt7530.h         |  1 -
 include/net/dsa.h                | 21 ++++++++
 net/dsa/dsa_priv.h               |  2 +
 net/dsa/port.c                   | 85 ++++++++++++++++++++++++++++++--
 net/dsa/slave.c                  | 24 ++-------
 net/dsa/switch.c                 | 31 +++++++++++-
 9 files changed, 156 insertions(+), 63 deletions(-)

-- 
2.17.1