netdev - Re: net: dsa: mv88e6xxx: Request for stable inclusion

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:   Tue, 28 Mar 2023 18:21:58 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Fabio Estevam <festevam@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        netdev <netdev@...r.kernel.org>, stable <stable@...r.kernel.org>
Subject: Re: net: dsa: mv88e6xxx: Request for stable inclusion

Hi Fabio,

On Tue, Mar 28, 2023 at 11:51:35AM -0300, Fabio Estevam wrote:
> Hi,
> 
> I am running kernel 6.1 on a system with a mv88e6320 and can easily
> trigger a flood of "mv88e6085 30be0000.ethernet-1:00: VTU member
> violation for vid 10, source port 5" messages.
> 
> When this happens, the Ethernet audio that passes through the switch
> causes a loud noise in the speaker.
> 
> Backporting the following commits to 6.1 solves the problem:
> 
> 4bf24ad09bc0 ("net: dsa: mv88e6xxx: read FID when handling ATU violations")
> 8646384d80f3 ("net: dsa: mv88e6xxx: replace ATU violation prints with
> trace points")
> 9e3d9ae52b56 ("net: dsa: mv88e6xxx: replace VTU violation prints with
> trace points")
> 
> Please apply them to 6.1-stable tree.
> 
> Thanks,
> 
> Fabio Estevam

For my information, is there any relationship between the audio samples
that (presumably) get packet drops resulting in noise, and the traffic
getting VTU member violations? In other words, is the audio traffic sent
using VID 10 on switch port 5?

I don't quite understand, since VLAN-filtered traffic should be dropped,
what is the reason why the trace point patches would help. My only
explanation is that the audio traffic passing through the switch *also*
passes through the CPU, and the trace points reduce CPU load caused by
an unrelated (and rogue) traffic stream.

If this isn't the case, and you see VTU violations as part of normal
operation, I would say that's a different problem for which we would
need more details.