netdev - Re: Configuring ethernet link fails with No such device

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] [day] [month] [year] [list]

Message-ID: <f888bb515fbeb7f8202bda89509eed8a@agner.ch>
Date:	Tue, 12 Apr 2016 18:29:35 -0700
From:	Stefan Agner <stefan@...er.ch>
To:	David Miller <davem@...emloft.net>, teg@...m.no,
	f.fainelli@...il.com
Cc:	bob.ham@...labora.com, systemd-devel@...ts.freedesktop.org,
	netdev@...r.kernel.org, fabio.estevam@...escale.com,
	l.stach@...gutronix.de, u.kleine-koenig@...gutronix.de
Subject: Re: Configuring ethernet link fails with No such device

[added Tom Gundersen as he seemed to have worked on udev's net link
built-in]

On 2016-04-12 08:44, David Miller wrote:
> From: Bob Ham <bob.ham@...labora.com>
> Date: Tue, 12 Apr 2016 09:58:12 +0100
> 
>> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
>>
>>> Or in other words: Is this a Kernel or systemd issue?
>>
>> From what I recall, both; an issue with the FEC driver, and issues in
>> systemd/udevd's handling of link-level settings.
> 
> This is my impression of the situation as well.

The execution order looks as follows for the FEC driver (taken from a
recent kernel with some additional printks, serial console):

...
[    1.157086] fec_probe
...
[    1.190350] fec_enet_mii_init
[    1.205446] libphy: fec_enet_mii_bus: probed
[    1.217849] fec 400d1000.ethernet eth0: registered PHC device 0
...
[   10.751060] dev_ethtool, rc -19 => (ETHTOOL_GSET) Too early...
[   11.262333] fec_enet_open
[   11.479928] fec_enet_mii_probe => Or/and too late...

Looking at the journal:
...
Apr 13 01:02:49 colibri-vf systemd[1]: Started udev Coldplug all
Devices.
...
Apr 13 01:02:50 colibri-vf kernel: mdev_ethtool, rc -19
...
Apr 13 01:02:50 colibri-vf systemd-udevd[197]: Could not set speed or
duplex of eth0 to 0 Mbps (half): No such device
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_open
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_mii_probe

The service "udev Coldplug all Devices" essentially executes:
udevadm trigger --type=subsystems --action=add ; udevadm trigger
--type=devices --action=add

I guess the "add" udev event is generated due to the fact that the
device has successfully been probed. If the kernel is allowed to
initialize the PHY as late as at open time, systemd should configure the
link at a point after link up... Do you agree on that?

Afact there is no udev event on link up, hence this would not be a mere
udev rule change...?

So I think the issue is either a systemd/udev issue or a FEC driver
issue. And the solution is one of this two options:
- Move (all the) PHY probes at driver probe time, then the PHY will be
probed when udev processes the add event
- Or move systemd/networkd/udev link processing, set the link settings
only after the device has been opened (link up).

Florian brought up a good point in another answer:
> 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.

Therefor I think only option 2 is actually viable.

--
Stefan