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: <871r2l2xxh.fsf@waldekranz.com>
Date:   Thu, 09 Dec 2021 23:52:42 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Add tx fwd offload PVT on
 intermediate devices

On Fri, Dec 10, 2021 at 00:41, Vladimir Oltean <olteanv@...il.com> wrote:
> On Thu, Dec 09, 2021 at 11:24:24PM +0100, Tobias Waldekranz wrote:
>> In a typical mv88e6xxx switch tree like this:
>> 
>>   CPU
>>    |    .----.
>> .--0--. | .--0--.
>> | sw0 | | | sw1 |
>> '-1-2-' | '-1-2-'
>>     '---'
>> 
>> If sw1p{1,2} are added to a bridge that sw0p1 is not a part of, sw0
>> still needs to add a crosschip PVT entry for the virtual DSA device
>> assigned to represent the bridge.
>> 
>> Fixes: ce5df6894a57 ("net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT")
>> Signed-off-by: Tobias Waldekranz <tobias@...dekranz.com>
>> ---
>
> This makes sense. Sorry, my Turris MOX has 3 cascaded switches but I
> only test it using a single bridge that spans all of the ports.
> So this is why in my case the DSA and CPU ports could receive packets
> using the virtual bridge device, because mv88e6xxx_port_vlan() had been
> called on them through the direct mv88e6xxx_port_bridge_join(), not
> through mv88e6xxx_crosschip_bridge_join().

Yeah this is by far the most common setup, that's why I missed it as
well.

> I guess you have a use case
> where some leaf ports are in a bridge but some upstream ports aren't,
> and this is how you caught this?

I've been doing some work on running kselftest-like tests on a multichip
mv88e6xxx system. In that process, I discovered this issue along with a
whole slew of other nasty things related to isolation of standalone
ports.

I am finalizing a series to tackle that which (while not exactly
elegant) should get the job done. Stay tuned :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ