netdev - Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFBinCCnn-DTBYh-vBGpGBCfnsQ-kSGPM2brwpN3G4RZQKO-Ug@mail.gmail.com>
Date:   Sat, 9 Jul 2022 00:27:13 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Petr Machata <petrm@...dia.com>,
        Ido Schimmel <idosch@...dia.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Arun Ramadoss <arun.ramadoss@...rochip.com>,
        Hauke Mehrtens <hauke@...ke-m.de>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

Hi Vladimir,

On Fri, Jul 8, 2022 at 2:09 PM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
> On Fri, Jul 08, 2022 at 12:00:33PM +0200, Martin Blumenstingl wrote:
> > That made me look at another selftest and indeed: most of the
> > local_termination.sh tests are passing (albeit after having to make
> > some changes to the selftest scripts, I'll provide patches for these
> > soon)
> >
> > None (zero) of the tests from bridge_vlan_unaware.sh and only a single
> > test from bridge_vlan_aware.sh ("Externally learned FDB entry - ageing
> > & roaming") are passing for me on GSWIP.
> > Also most of the ethtool.sh tests are failing (ping always reports
> > "Destination Host Unreachable").
>
> I don't recall having run ethtool.sh, so I don't know what's the status
> there.
OK, no worries there

> > I guess most (or at least more) of these are supposed to pass? Do you
> > want me to open another thread for this or is it fine to reply here?
>
> So yes, the intention is for the selftests to pass, but I wouldn't be
> surprised if they don't. They didn't when I started this effort for the
> ocelot/felix DSA driver either, it's most likely that individual drivers
> will need changes, that's kind of the whole point of having selftests,
> to have implementations that are uniform in terms of behavior.
> For the ocelot driver, the tests symlinked in the DSA folder do pass
> (with the exception of the locked port test, which isn't implemented,
> and the bridge local_termination.sh tests, but that's a bridge problem
> and not a driver problem). I should have a remote setup and I should be
> able to repeat some tests if necessary.
>
> I think it would be a good idea to create a new email thread with the
> relevant DSA maintainers for selftest status on GSWIP. You'll need to
> gather some information on what exactly fails when things fail.
> The way I prefer to do this is to run the test itself with "bash -x
> ./bridge_vlan_unaware.sh swp0 swp1 swp2 swp3", analyze a bit where
> things get stuck, then edit the script, put a "bash" command after the
> failing portion, and run the selftest again; this gives me a subshell
> with all the VRFs configured from which I have more control and can
> re-run the commands that just failed (I copy them from right above,
> they're visible when run with bash -x). Then I try to manually check
> counters, tcpdump, things like that.
I already found "bash -x" and used a similar trick (launching tcpdump
before the failing portion). But it's good to have it written down!
Thanks a lot again for all your detailed explanations and the time
you've taken to help me out!
I'll start a new thread on this in the next few days.


Best regards,
Martin