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:	Mon, 11 Apr 2016 16:10:53 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Stefan Agner <stefan@...er.ch>,
	systemd-devel@...ts.freedesktop.org, netdev@...r.kernel.org,
	davem@...emloft.net
Cc:	fabio.estevam@...escale.com, l.stach@...gutronix.de,
	u.kleine-koenig@...gutronix.de, bryan.wu@...onical.com,
	bob.ham@...labora.com, Andrew Lunn <andrew@...n.ch>
Subject: Re: Configuring ethernet link fails with No such device

On 11/04/16 15:46, Stefan Agner wrote:
> Hi All,
> 
> I traced an issue in which we tried configuring duplex mode and speed in
> a systemd-udevd .link file failed with the following error:
> "Could not set speed or duplex of eth0 to 0 Mbps (half): No such device"
> 
> The FEC driver (fec_main.c) does not initialize phy_dev until the device
> has been opened, and therefor the callback fec_enet_(get|set)_settings
> returns -19.
> 
> What is the expectation/definition when link configuration should be
> possible? Only after the network device got opened or before?

It seems to me like systemd tries to configure the device while we are
still opening it, which is arguably something that can be done, but you
are in a transient state, the interface is not completely ready yet.

> 
> Or in other words: Is this a Kernel or systemd issue? At what point is
> link configuration "guaranteed" to work?

Past ndo_open() had a chance to return, therefore connect to the PHY
device, is when the configuration/information querying is able to succeed.

> 
> It seems that the FEC driver used to probe the PHY earlier, it has been
> moved to the open callback with commit 418bd0d4df ("netdev/fec: fix
> ifconfig eth0 down hang issue")...

Part of the reason for doing that, is that probing for the PHY during
the driver's probe function could leave you with unused HW that is
powered on for no good reason. Until we get into ndo_open, we have no
clue if the interface is going to be used or not, so it is better to
move part of the HW initialization as late as possible in the process.

> 
> There has been a similar report on the systemd-devel mailing list a
> while ago, probably the same underlying issue:
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg33186.html
> 
> --
> Stefan
> 


-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ