Re: [PATCH v8 net-next 10/12] net: transfer rtnl_lock() requirement from ethtool_set_ethtool_phy_ops() to caller
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2023-07-18 14:31:28
Also in:
lkml, netdev
On Mon, Jul 17, 2023 at 06:27:07PM +0300, Vladimir Oltean wrote:
phy_init() and phy_exit() will have to do more stuff under rtnl_lock() in a future change. Since rtnl_unlock() -> netdev_run_todo() does a lot of stuff under the hood, it's a pity to lock and unlock the rtnetlink mutex twice in a row. Change the calling convention such that the only caller of ethtool_set_ethtool_phy_ops(), phy_device.c, provides a context where the rtnl_mutex is already acquired. Note that phy_exit() wasn't performing the opposite teardown of phy_init(). Reverse mdio_bus_init() with ethtool_set_ethtool_phy_ops(), so that this is now the case.
To me, this looks buggy.
quoted hunk ↗ jump to hunk
@@ -3451,11 +3452,14 @@ static int __init phy_init(void) { int rc; + rtnl_lock(); + ethtool_set_ethtool_phy_ops(&phy_ethtool_phy_ops); + rtnl_unlock(); + rc = mdio_bus_init(); if (rc) return rc;
If mdio_bus_init() fails, and phylib is built as a module, then we leave ethtool_phy_ops pointing into module space that has potentially been freed or re-used for another module. This error path needs to properly clean up. The same is also true for the other failure paths in phy_init() which already do not cater for their failures leaving a dangling pointer in ethtool_phy_ops. This should probably be fixed first in a separate patch for the net tree. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel