linux-kernel - Aw: Re: [RFC/RFT v1] net: ethernet: mtk_eth_soc: drop generic vlan rx offload, only use DSA untagging

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: <trinity-753f5441-ab68-43df-9640-b9b0db7f8491-1681643386248@3c-app-gmx-bap64>
Date:   Sun, 16 Apr 2023 13:09:46 +0200
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>
Cc:     Frank Wunderlich <linux@...web.de>, Felix Fietkau <nbd@....name>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Daniel Golle <daniel@...rotopia.org>,
        John Crispin <john@...ozen.org>,
        Sean Wang <sean.wang@...iatek.com>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Aw: Re: [RFC/RFT v1] net: ethernet: mtk_eth_soc: drop generic vlan
 rx offload, only use DSA untagging

> Gesendet: Sonntag, 16. April 2023 um 12:55 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@...nc9.com>
> On 16.04.2023 13:15, Frank Wunderlich wrote:
> > Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <arinc.unal@...nc9.com>:
> >> On 16.04.2023 12:10, Frank Wunderlich wrote:
> >>> From: Felix Fietkau <nbd@....name>
> >>>
> >>> Through testing I found out that hardware vlan rx offload support seems to
> >>> have some hardware issues. At least when using multiple MACs and when receiving
> >>> tagged packets on the secondary MAC, the hardware can sometimes start to emit
> >>> wrong tags on the first MAC as well.
> >>>
> >>> In order to avoid such issues, drop the feature configuration and use the
> >>> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
> >>> only use one MAC.
> >>
> >> MT7621 devices most certainly use both MACs.
> >>
> >>>
> >>> Tested-by: Frank Wunderlich <frank-w@...lic-files.de>
> >>> Signed-off-by: Felix Fietkau <nbd@....name>
> >>> Signed-off-by: Frank Wunderlich <frank-w@...lic-files.de>
> >>> ---
> >>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
> >>> and the original bug is not handled again.
> >>>
> >>> it reverts changes from vladimirs patch
> >>>
> >>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
> >>
> >> Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
> > 
> > As far as i understood, vladimirs patch fixes one
> > cornercase of hw rx offload where felix original
> > patch was fixing more..sent it as rft to you to test
> > if your bug (which vladimir fixed) is not coming in
> > again. If it does we can try to merge both
> > attempts. But current state has broken vlan on
> > bpi-r3 non-dsa gmac1 (sfp-wan).
> 
> I tested this patch on MT7621AT and MT7623NI SoCs on the current 
> linux-next. Port 0 keeps working fine.

looks good so far ;)

> So when you use VLANs on non-DSA gmac1, network connectivity is broken?

the vlan does not work...it looks it is untagged on rx path. i see tagged frames on the other
end, send tagged back and these are not received tagged on the mac...this behaviour has brought
me to felix patch i had rebased here. the non-vlan traffic is not affected.

> I've got an MT7621AT device which gmac1 is connected to an external phy 
> (sfp-wan, the same case as yours). I'll test VLANs there. See if MT7621 
> is affected by this as well since the patch log here states this feature 
> is kept enabled for MT7621 because only gmac0 is used which is false.

good idea :)

> Arınç