netdev - Re: Component API not right for DSA?

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: <20240918125953.l64f5r5qq4pomvnb@skbuf>
Date: Wed, 18 Sep 2024 15:59:53 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Russell King <linux@...linux.org.uk>,
	Florian Fainelli <f.fainelli@...il.com>,
	Saravana Kannan <saravanak@...gle.com>, netdev@...r.kernel.org
Subject: Re: Component API not right for DSA?

On Wed, Sep 18, 2024 at 02:48:26PM +0200, Andrew Lunn wrote:
> > 2. I honestly don't think that the workaround to wait until the routing
> >    table is complete is in the best interest of DSA. The larger context
> >    here is that one can imagine DSA trees operating in a "degraded state"
> >    where not all switches are present. For example, if there is a chain
> >    of 3 switches and the last switch is missing, nothing prevents the
> >    first 2 from doing their normal job. There is actually a customer who
> >    wants to take down a switch for regular maintainance, while keeping
> >    the rest of the system operational.
> 
> Do you plan to use hotplug for this? The user interfaces disappear
> when the switch is removed? The kernel will then try to clean up all
> state for those interfaces, removing them from bridges and bonds etc?
> 
> It will be interesting to see what happens if something in userspace
> is keeping a reference on the interfaces, so they cannot be destroyed,
> and then the switch is probed again, and we have a name clash. I've
> seen USB interfaces not fully disappear when i had a flaky USB hub
> causing disconnects.
> 
> I wounder what configuration exists which is transparent to
> Linux. Hotplugging interfaces won't deal with this.  The routing table
> is one, it is a DSA concept. You will need to change the internal API,
> be able to tell a switch the topology has changed, it needs to reload
> its routing table. But i don't think that is hard.
> 
> 	Andrew

Nope, it won't be so complicated - removal of switches would be
initiated by user space (in turn, by the user). For this use case, it is
known ahead of time by a few seconds that a switch is going to disappear,
so regular driver unbinding should be fine. Later attempts to rebind the
driver to the device should fail as long as it is physically inaccessible.

Side note - there is another related request to take down a PHY of a
single port for maintainance, with the same simplifying assumption that
it is known ahead of time by a few seconds when this is needed, and with
the same requirement that the rest of the switch ports must go on. I was
planning to handle that in a similar way: user space puts the net_device
down, and it cannot be put back up until the PHY is accessible again.
I need to submit some more changes to DSA for that to work (phylink_of_phy_connect()
done at ndo_open() time), but that was much easier compared to adapting
the outcome of dsa_routing_port(), and thus drivers, to dynamic changes
to the rtable.