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-next>] [day] [month] [year] [list]
Date:   Tue,  5 Jul 2022 20:31:11 +0300
From:   Vladimir Oltean <>
Cc:     "David S. Miller" <>,
        Eric Dumazet <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Xiaoliang Yang <>,
        Claudiu Manoil <>,
        Alexandre Belloni <>,, Andrew Lunn <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        Petr Machata <>,
        Ido Schimmel <>,
        Woojung Huh <>,
        Oleksij Rempel <>,
        Arun Ramadoss <>,
        Hauke Mehrtens <>,
        Martin Blumenstingl <>
Subject: [RFC PATCH net-next 0/3] Delete ds->configure_vlan_while_not_filtering

Even though this isn't documented explicitly, we have told driver
writers on different occasions (mainly during review) that
ds->configure_vlan_while_not_filtering is an option which ideally should
not exist, is opt-in, that we should work towards deleting it, and new
drivers should not opt into it.

However, what seems to be happening is that new drivers still seem to be
able to slip through the cracks and get introduced with the VLAN
skipping legacy behavior.

Such is the case of the Microchip LAN937x, which was merged in v15,
after being taken over by Arun Ramadoss from Prasanna Vengateshan.

I had asked Prasanna to remove the deprecated option from existing KSZ
and yet somehow, how we are in the situation that after Arun's KSZ
driver refactoring to use more common code, the quirks are common too,
including ds->configure_vlan_while_not_filtering being inherited by the
new LAN937x driver.

Maybe the problem was that I wasn't specific enough about what should be
done to move forward, so this patch set attempts to be a more concrete
step. I've created a selftest that captures what I believe to be the
essence of the workaround, and I'd like to ask maintainers with access
to KSZ and to GSWIP hardware to test it and to propose fixes.

Vladimir Oltean (3):
  selftests: forwarding: add a vlan_deletion test to bridge_vlan_unaware
  net: dsa: ar9331: remove ds->configure_vlan_while_not_filtering
  net: dsa: never skip VLAN configuration

 drivers/net/dsa/lantiq_gswip.c                |  2 --
 drivers/net/dsa/microchip/ksz_common.c        |  2 --
 drivers/net/dsa/qca/ar9331.c                  |  2 --
 include/net/dsa.h                             |  7 ------
 net/dsa/dsa2.c                                |  2 --
 net/dsa/dsa_priv.h                            |  1 -
 net/dsa/port.c                                | 14 -----------
 net/dsa/slave.c                               | 22 +---------------
 .../net/forwarding/     | 25 ++++++++++++++++---
 9 files changed, 23 insertions(+), 54 deletions(-)


Powered by blists - more mailing lists