netdev - Re: [PATCH net-next] net: dsa: mv88e6xxx: Add tx fwd offload PVT on intermediate devices

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]

Date:   Sat, 11 Dec 2021 22:20:28 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, andrew@...n.ch, vivien.didelot@...il.com,
        f.fainelli@...il.com, olteanv@...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 21:18, Jakub Kicinski <kuba@...nel.org> wrote:
> On Thu,  9 Dec 2021 23:24:24 +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")
>
> Hm, should this go to net? The commit above is in 5.15 it seems.

Since there was no cover letter for this patch I put that motivation
after the commit message cutoff:

    Though this is a bugfix, it still targets net-next as it depends on
    the recent work done by Vladimir here:

    https://lore.kernel.org/netdev/20211206165758.1553882-1-vladimir.oltean@nxp.com/

I have patches for 5.15 but the implementation is completely
different. Given that (1) multichip devices are pretty uncommon to begin
with and (2) that this configuration is also rare, I thought it might be
more trouble than it was worth.

Let me know if you want me to send that too - but independent of that, I
think this should go in on net-next.