netdev - Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7dfe15571370dfb5348a3d0e5478f62c@kapio-technology.com>
Date:   Thu, 25 Aug 2022 12:27:01 +0200
From:   netdev@...io-technology.com
To:     Ido Schimmel <idosch@...dia.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
        Ivan Vecera <ivecera@...hat.com>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Shuah Khan <shuah@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry
 flag to drivers

On 2022-08-25 11:23, Ido Schimmel wrote:
>> 
>> 
>> Ido, I am not so known to the selftests, so I am wondering why I don't 
>> see
>> either check_err or check_fail fail, whichever I use, when I think 
>> they
>> should and then they are not really checking...
>> 
>> 
>>         local mac=10:20:30:30:20:10
>> 
>> 
>>         $MZ $h1 -t udp -a $mac -b rand
>>         bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 
>> locked"
>>         check_err $? "MAB station move: no locked entry on first 
>> injection"
>> 
>>         $MZ $h2 -t udp -a $mac -b rand
>>         bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 
>> locked"
>>         check_err $? "MAB station move: locked entry did not move"
>> 
>> What is wrong here?
> 
> Did you try adding a sleep between mausezahn and the FDB dump? At least
> that is what learning_test() is doing. It is possible that the packet 
> is
> not sent / processed fast enough for the bridge to learn it before the
> dump.
> 

I missed the call to log_test at the end of the test.

>> 
>> For a mv88e6xxx test I guess I can make a check to verify that this 
>> driver
>> is in use?
> 
> Not in a generic forwarding test. Maybe in
> tools/testing/selftests/drivers/net/dsa/
> 
> My preference would be to get as much tests as possible in
> tools/testing/selftests/net/forwarding/bridge_locked_port.sh.

I now have a roaming test in 
tools/testing/selftests/net/forwarding/bridge_locked_port.sh, but it 
will not pass with mv88e6xxx as it is meant for the SW bridge.

I can check if the sticky flag is set on the locked entry and then skip 
the test if it is.

The bridge_locked_port.sh test is linked in 
tools/testing/selftests/drivers/net/dsa/, but if I cannot check if the 
mv88e6xxx driver or other switchcores are in use, I cannot do more.

> 
> I'm not sure which tests you are planning for mv88e6xxx, but we can 
> pass
> / fail test cases based on the flags we observe in the FDB dump. For
> example, if the entry has the "sticky" flag, then the expectation is
> that the roaming test will fail. Otherwise, it should pass.