netdev - Re: [PATCH v3 net-next 21/24] net: dsa: sja1105: Prevent PHY jabbering during switch reset

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: <20190413165411.GK17901@lunn.ch>
Date:   Sat, 13 Apr 2019 18:54:11 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     f.fainelli@...il.com, vivien.didelot@...il.com,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, georg.waibel@...sor-technik.de
Subject: Re: [PATCH v3 net-next 21/24] net: dsa: sja1105: Prevent PHY
 jabbering during switch reset

On Sat, Apr 13, 2019 at 04:28:19AM +0300, Vladimir Oltean wrote:
> Resetting the switch at runtime is currently done while changing the
> vlan_filtering setting (due to the required TPID change).
> 
> But reset is asynchronous with packet egress, and the switch core will
> not wait for egress to finish before carrying on with the reset
> operation.
> 
> As a result, a connected PHY such as the BCM5464 would see an
> unterminated Ethernet frame and start to jabber (repeat the last seen
> Ethernet symbols - jabber is by definition an oversized Ethernet frame
> with bad FCS). This behavior is strange in itself, but it also causes
> the MACs of some link partners (such as the FRDM-LS1012A) to completely
> lock up.
> 
> So as a remedy for this situation, when switch reset is required, simply
> inhibit Tx on all ports, and wait for the necessary time for the
> eventual one frame left in the egress queue (not even the Tx inhibit
> command is instantaneous) to be flushed.
> 
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew