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]
Date:   Wed, 6 Jul 2022 18:33:18 +0200
From:   Martin Blumenstingl <>
To:     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 <>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

Hi Vladimir,

On Tue, Jul 5, 2022 at 7:32 PM Vladimir Oltean <> wrote:
> Stop protecting DSA drivers from switchdev VLAN notifications emitted
> while the bridge has vlan_filtering 0, by deleting the deprecated bool
> ds->configure_vlan_while_not_filtering opt-in. Now all DSA drivers see
> all notifications and should save the bridge PVID until they need to
> commit it to hardware.
> The 2 remaining unconverted drivers are the gswip and the Microchip KSZ
> family. They are both probably broken and would need changing as far as
> I can see:
> - For lantiq_gswip, after the initial call path
>   -> gswip_port_bridge_join
>      -> gswip_vlan_add_unaware
>         -> gswip_switch_w(priv, 0, GSWIP_PCE_DEFPVID(port));
>   nobody seems to prevent a future call path
>   -> gswip_port_vlan_add
>      -> gswip_vlan_add_aware
>         -> gswip_switch_w(priv, idx, GSWIP_PCE_DEFPVID(port));
Thanks for bringing this to my attention!

I tried to reproduce this issue with the selftest script you provided
(patch #1 in this series).
Unfortunately not even the ping_ipv4 and ping_ipv6 tests from are working for me, nor are the tests from
I suspect that this is an issue with OpenWrt: I already enabled bash,
jq and the full ip package, vrf support in the kernel. OpenWrt's ping
command doesn't like a ping interval of 0.1s so I replaced that with
an 1s interval.

I will try to get the selftests to work here but I think that
shouldn't block this patch.

Best regards,

Powered by blists - more mailing lists