netdev - Re: [PATCH net-next v4 08/11] net: dsa: realtek: clean user_mii

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9657a15e-7c60-4244-9c27-327d96b7b76b@lunn.ch>
Date: Tue, 30 Jan 2024 16:02:51 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Arınç ÜNAL <arinc.unal@...nc9.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <olteanv@...il.com>,
	Luiz Angelo Daros de Luca <luizluca@...il.com>,
	netdev@...r.kernel.org, linus.walleij@...aro.org,
	alsi@...g-olufsen.dk, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, ansuelsmth@...il.com
Subject: Re: [PATCH net-next v4 08/11] net: dsa: realtek: clean user_mii_bus
 setup

On Tue, Jan 30, 2024 at 05:40:26PM +0300, Arınç ÜNAL wrote:
> On 29.01.2024 19:22, Florian Fainelli wrote:
> > 
> > 
> > On 1/29/2024 8:15 AM, Vladimir Oltean wrote:
> > >  From other discussions I've had, there seems to be interest in quite the
> > > opposite thing, in fact. Reboot the SoC running Linux, but do not
> > > disturb traffic flowing through the switch, and somehow pick up the
> > > state from where the previous kernel left it.
> > 
> > Yes this is actually an use case that is very dear to the users of DSA in an airplane. The entertainment system in the seat in front of you typically has a left, CPU/display and right set of switch ports. Across the 300+ units in the plane each entertainment systems runs STP to avoid loops being created when one of the display units goes bad. Occasionally cabin crew members will have to swap those units out since they tend to wear out. When they do, the switch operates in a headless mode and it would be unfortunate that plugging in a display unit into the network again would be disrupting existing traffic. I have seen out of tree patches doing that, but there was not a good way to make them upstream quality.
> 
> This piqued my interest. I'm trying to understand how exactly plugging in a
> display unit into the network would disrupt the traffic flow. Is this about
> all network interfaces attached to the bridge interface being blocked when
> a new link is established to relearn the changed topology?

The hardware is split into two parts, a cradle and the display
unit. The switch itself is in the cradle embedded in the seat
back. The display unit contains the CPU, GPU, storage etc. There is a
single Ethernet interface between the display unit and the cradle,
along with MDIO, power, audio cables for the headphone jack etc.

When you take out the display unit, you disconnect the switches
management plain. The CPU has gone, and its the CPU running STP,
sending and receiving BPDUs, etc. But the switch is still powered, and
switching packets, keeping the network going, at least for a while.

When you plug in a display unit, it boots. As typical for any computer
booting, it assumes the hardware is in an unknown state, and hits the
switch with a reset. That then kills the local networking, and it
takes a little while of the devices around it to swap to a redundant
path. The move from STP to RSTP has been made, which speeds this all
up, but you do get some disruption.

It can take a while for the display unit to boot into user space and
reconfigure the switch. Its only when that is complete can the switch
rejoin the network.

Rather than hit the switch with a reset, it would be better to somehow
suck the current configuration out of the switch and prime the Linux
network stack with that configuration. But that is a totally alien
concept to Linux.

	Andrew