linux-kernel - Re: [PATCH net-next v13 05/13] net: ethtool: Allow passing a phy index for some commands

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: Sun, 16 Jun 2024 17:07:08 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	thomas.petazzoni@...tlin.com, Eric Dumazet <edumazet@...gle.com>,
	Paolo Abeni <pabeni@...hat.com>,
	linux-arm-kernel@...ts.infradead.org,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Herve Codina <herve.codina@...tlin.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Köry Maincent <kory.maincent@...tlin.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Marek Behún <kabel@...nel.org>,
	Piergiorgio Beruto <piergiorgio.beruto@...il.com>,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	Nicolò Veronese <nicveronese@...il.com>,
	Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
	Nathan Chancellor <nathan@...nel.org>,
	Antoine Tenart <atenart@...nel.org>
Subject: Re: [PATCH net-next v13 05/13] net: ethtool: Allow passing a phy
 index for some commands

On Sun, Jun 16, 2024 at 05:21:25PM +0200, Andrew Lunn wrote:
> On Sun, Jun 16, 2024 at 06:02:31PM +0200, Maxime Chevallier wrote:
> > Hello Jakub,
> > 
> > On Thu, 13 Jun 2024 18:26:13 -0700
> > Jakub Kicinski <kuba@...nel.org> wrote:
> > 
> > > On Fri,  7 Jun 2024 09:18:18 +0200 Maxime Chevallier wrote:
> > > > +		if (tb[ETHTOOL_A_HEADER_PHY_INDEX]) {
> > > > +			struct nlattr *phy_id;
> > > > +
> > > > +			phy_id = tb[ETHTOOL_A_HEADER_PHY_INDEX];
> > > > +			phydev = phy_link_topo_get_phy(dev,
> > > > +						       nla_get_u32(phy_id));  
> > > 
> > > Sorry for potentially repeating question (please put the answer in the
> > > commit message) - are phys guaranteed not to disappear, even if the
> > > netdev gets closed? this has no rtnl protection
> > 
> > I'll answer here so that people can correct me if I'm wrong, but I'll
> > also add it in the commit logs as well (and possibly with some fixes
> > depending on how this discussion goes)
> > 
> > While a PHY can be attached to/detached from a netdevice at open/close,
> > the phy_device itself will keep on living, as its lifetime is tied to
> > the underlying mdio_device (however phy_attach/detach take a ref on the
> > phy_device, preventing it from vanishing while it's attached to a
> > netdev)
> 
> It gets interesting with copper SFP. They contain a PHY, and that PHY
> can physically disappear at any time. What i don't know is when the
> logical representation of the PHY will disappear after the hotunplug
> event.

On a SFP module unplug, the following upstream device methods will be
called in order:
1. link_down
2. module_stop
3. disconnect_phy

At this point, the PHY device will be removed (phy_device_remove()) and
freed (phy_device_free()), and shortly thereafter, the MDIO bus is
unregistered and thus destroyed.

In response to the above, phylink will, respectively for each method:

1. disable the netdev carrier and call mac_link_down()
2. call phy_stop() on the attached PHY
3. remove the PHY from phylink, and then call phy_disconnect(),
   disconnecting it from the netdev.

Thus, when a SFP PHY is being removed, phylib will see in order the
following calls:

	phy_disconnect()
	phy_device_remove()
	phy_device_free()

Provided the topology linkage is removed on phy_disconnect() which
disassociates the PHY from the netdev, SFP PHYs should be fine.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!