Re: [PATCH v2 net] net: phy: clear phydev->devlink when the link is deleted

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Jun 03, 2025 at 01:39:47PM -0700, Abhishek Chauhan (ABC) wrote:
> 
> 
> On 5/23/2025 8:19 AM, Florian Fainelli wrote:
> > 
> > 
> > On 5/23/2025 1:37 AM, Wei Fang wrote:
> >> There is a potential crash issue when disabling and re-enabling the
> >> network port. When disabling the network port, phy_detach() calls
> >> device_link_del() to remove the device link, but it does not clear
> >> phydev->devlink, so phydev->devlink is not a NULL pointer. Then the
> >> network port is re-enabled, but if phy_attach_direct() fails before
> >> calling device_link_add(), the code jumps to the "error" label and
> >> calls phy_detach(). Since phydev->devlink retains the old value from
> >> the previous attach/detach cycle, device_link_del() uses the old value,
> >> which accesses a NULL pointer and causes a crash. The simplified crash
> >> log is as follows.
> >>
> >> [   24.702421] Call trace:
> >> [   24.704856]  device_link_put_kref+0x20/0x120
> >> [   24.709124]  device_link_del+0x30/0x48
> >> [   24.712864]  phy_detach+0x24/0x168
> >> [   24.716261]  phy_attach_direct+0x168/0x3a4
> >> [   24.720352]  phylink_fwnode_phy_connect+0xc8/0x14c
> >> [   24.725140]  phylink_of_phy_connect+0x1c/0x34
> >>
> >> Therefore, phydev->devlink needs to be cleared when the device link is
> >> deleted.
> >>
> >> Fixes: bc66fa87d4fd ("net: phy: Add link between phy dev and mac dev")
> >> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > 
> @Wei 
> What happens in case of shared mdio ? 
> 
> 1. Device 23040000 has the mdio node of both the ethernet phy and device 23000000 references the phy-handle present in the Device 23040000
> 2. When rmmod of the driver happens 
> 3. the parent devlink is already deleted. 
> 4. This cause the child mdio to access an entry causing a corruption. 
> 5. Thought this fix would help but i see that its not helping the case. 
> 
> Wondering if this is a legacy issue with shared mdio framework. 

The device link does nothing for this as it has DL_FLAG_STATELESS set,
which only affects suspend/resume/shutdown ordering, and with
DL_FLAG_PM_RUNTIME also set, runtime PM.

The device probe/removal ordering is unaffected. Maybe that's a
problem, but it needs careful consideration to change.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!