netdev - Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

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]

Date:   Wed, 1 Feb 2017 18:56:46 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>,
        David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, andrew@...n.ch, maowenan@...wei.com
Subject: Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

On 02/01/2017 11:10 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 01:59:38PM -0500, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@...il.com>
>> Date: Wed, 1 Feb 2017 10:55:46 -0800
>>
>>> You are right, but there is still a fundamental problem IMHO in that you
>>> should not be able to rmmod a PHY driver as long as a network device is
>>> attached to the PHY, and if the PHY driver is attached from several
>>> different network devices, they should all have a way to prevent a PHY
>>> driver rmmod, each of them incrementing the driver refcount, which is
>>> what the patche from Maowan does here.
>>
>> It briefly occurred to me that we might want to be able to disconnect
>> PHYs to allow an unload using notifiers, the same way that when you
>> take a netdevice down we emit notifiers so that all of the references
>> to the netdevice can release themselves.
>>
>> I have no idea how well that would work, or whether it is valuable or
>> not.  But it is another way to handle this.
>>
>> But that is a longer-term thing even if we want to go that way, and
>> thus grabbing the proper refs is the right things to do for now.
> 
> It's something I'm effectively already doing as part of my phylink
> project for SFP support, since you can hot-unplug a copper SFP
> module, and the PHY on the copper SFP module will be gone.  phylink,
> however, sits between the network driver and phylib, which isn't
> ideal.

So, for the "net" tree what should we do? I don't really think that we
should be able to let the PHY state machine run without a PHY driver
bound to the device, at best nothing happens, at worse, we just crash
and burn without further chance of recovering.
-- 
Florian