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 22:04:19 +0200
From:   Hauke Mehrtens <>
To:     Vladimir Oltean <>,
        Martin Blumenstingl <>
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 <>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

On 7/6/22 18:45, Vladimir Oltean wrote:
> Hi Martin,
> On Wed, Jul 06, 2022 at 06:33:18PM +0200, Martin Blumenstingl wrote:
>> 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.
> Thanks for the willingness to test!
> Somehow we should do something to make sure that the OpenWRT devices are
> able to run the selftests, because there's a large number of DSA switches
> intended for that segment and we should all be onboard (easily).
> I wonder, would it be possible to set up a debian chroot?

OpenWrt takes many packages like ping from busybox, but OpenWrt can also 
install the full versions. Adding a package which packs the self tests 
from the kernel and has the needed applications as dependencies would be 
nice. It would be nice to have such a thing in the OpenWrt package feed 
then we can easily test switches.

A debian chroot should be possible, but Debian supports MIPS32 BE only 
till Debian 10, I do not know if this recent enough. The GSWIP driver 
only works on SoCs with a MIPS32 BE CPU, I think this is similar for 
some other switches too. There are some old manuals in the Internet on 
how to run Debian on such systems.


Powered by blists - more mailing lists