netdev - Re: Cutting the link on ndo_stop - phy_stop or phy

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]

Date:   Tue, 4 Jun 2019 22:36:24 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Cutting the link on ndo_stop - phy_stop or phy_disconnect?

On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote:
> Hi,
> 
> I've been wondering what is the correct approach to cut the Ethernet link
> when the user requests it to be administratively down (aka ip link set dev
> eth0 down).
> Most of the Ethernet drivers simply call phy_stop or the phylink equivalent.

The first requirement is that phylink_start() is required to be called
in the ndo_open callback, and phylink_stop() is required to be called
in the ndo_stop callback - this is because when a SFP is used, it has
other effects beyond managing the PHY.

phylink_start() and phylink_stop() call the appropriately phylib
functions, and what happens to the PHY is up to phylib.

Whether a PHY has its link brought down or not is not set in stone:
some network cards, particularly those that do not use phylib, do not
bring the link down when the interface is brought down - doing so,
allows for (eg) a faster boot, and of course bringing an interface
up is faster if the link is already established.

Then there's the question about when the PHY is attached to the
network device.  Some drivers attach the PHY in their probe
function, others attach the PHY in their ndo_open method.  If the
PHY is attached in the ndo_open method, then the PHY must be
detached(disconnected) in the ndo_stop method - basically, ndo_stop
must reverse everything that ndo_open did.

> I see the ability to be able to put the PHY link administratively down a
> desirable feat. If it's left to negotiate/receive traffic etc while the MAC
> driver isn't completely set up and ready, in theory a lot of processing can
> happen outside of the operating system's control.

Normally the PHY receives traffic, and passes it to the MAC which
just ignores the signals it receives from the PHY, so no processing
beyond the PHY receiving the traffic happens.

Ultimately, whether you want the PHY to stay linked or not linked
is, imho, a policy that should be set by the administrator (consider
where a system needs to become available quickly after boot vs a
system where power saving is important.)  We don't, however, have
a facility to specify that policy though.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up