netdev - Re: [PATCH net-next] net: phy: probe PHY drivers synchronously

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]

Message-ID: <4a71aee8-370b-2a87-d549-a7fba5a5f873@gmail.com>
Date:   Fri, 27 Mar 2020 00:42:38 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: probe PHY drivers synchronously

On 27.03.2020 00:34, Andrew Lunn wrote:
> On Thu, Mar 26, 2020 at 07:16:23PM +0100, Heiner Kallweit wrote:
>> If we have scenarios like
>>
>> mdiobus_register()
>> 	-> loads PHY driver module(s)
>> 	-> registers PHY driver(s)
>> 	-> may schedule async probe
>> phydev = mdiobus_get_phy()
>> <phydev action involving PHY driver>
>>
>> or
>>
>> phydev = phy_device_create()
>> 	-> loads PHY driver module
>> 	-> registers PHY driver
>> 	-> may schedule async probe
>> <phydev action involving PHY driver>
>>
>> then we expect the PHY driver to be bound to the phydev when triggering
>> the action. This may not be the case in case of asynchronous probing.
>> Therefore ensure that PHY drivers are probed synchronously.
> 
> Hi Heiner
> 
Hi Andrew,

> We have been doing asynchronous driver loads since forever, and not
> noticed any problem. Do you have a real example of it going wrong?
> 
it's not about async driver loading, but about async probing once
the driver was loaded. See driver_allows_async_probing().
Default still is sync probing, except you explicitly request async
probing. But I saw some comments that the intention is to promote
async probing for more parallelism in boot process. I want to be
prepared for the case that the default is changed to async probing.
I'm not aware of any current issues, therefore I submitted it
for net-next.

> 	Andrew
> 
Heiner