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] [day] [month] [year] [list]
Date: Fri, 14 Jun 2024 16:47:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Paul Geurts <paul.geurts@...drive-technologies.com>
Cc: wei.fang@....com, shenwei.wang@....com, xiaoning.wang@....com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, imx@...ts.linux.dev, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fec_main: Register net device before initializing the
 MDIO bus

On Fri, Jun 14, 2024 at 10:40:50AM +0200, Paul Geurts wrote:
> > On Thu, Jun 13, 2024 at 04:41:11PM +0200, Paul Geurts wrote:
> > > Registration of the FEC MDIO bus triggers a probe of all devices
> > > connected to that bus. DSA based Ethernet switch devices connect to the
> > > uplink Ethernet port during probe. When a DSA based, MDIO controlled
> > > Ethernet switch is connected to FEC, it cannot connect the uplink port,
> > > as the FEC MDIO port is registered before the net device is being
> > > registered. This causes an unnecessary defer of the Ethernet switch
> > > driver probe.
> > > 
> > > Register the net device before initializing and registering the MDIO
> > > bus.
> > 
> > The problem with this is, as soon as you call register_netdev(), the
> > device is alive and sending packets. It can be sending packets even
> > before register_netdev() returns, e.g. in the case of NFS root. So
> > fec_enet_open() gets called, and tried to find its PHY. But the MDIO
> > bus is not registered yet....
> 
> Valid argument there. I was trying to make the initialization more efficient,
> but you are correct.

Any changes to make this more efficient probably needs to be generic,
and not in a specific Ethernet driver. One idea might be, when parsing
the DT node for the MDIO bus, look to see if the device on the bus has
a compatible which indicates it is not a PHY. If so, try to make the
driver core put the device straight into deferred state, without even
trying the first probe.

Also, look at driver core devlink stuff. It tries to keep track of
resource dependencies, and only probe devices when their resources are
available. It does not seem to understand DSA too well, and it might
be made better. But this is complex, we have dependency loops in
network drivers, which causes devlink issues.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ