summaryrefslogtreecommitdiff
path: root/net/unix/af_unix.c
diff options
context:
space:
mode:
authorSean Anderson <sean.anderson@linux.dev>2025-07-10 16:14:53 -0400
committerJakub Kicinski <kuba@kernel.org>2025-07-14 17:54:06 -0700
commita44312d58e78cfe8f0e72435101b7a9187b21d46 (patch)
treed44b94ad45a0ba1d11f121da0b3caa1bfc1f410c /net/unix/af_unix.c
parentff2ac4df58adb6d7721bb0ce6069e1bd0e613126 (diff)
net: phy: Don't register LEDs for genphy
If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Regular drivers do not have this problem since they are probed asynchronously (without RTNL held). Generic PHYs do not support LEDs anyway, so don't bother registering them. [JakubL this is a net-next version of commit f0f2b992d818 ("net: phy: Don't register LEDs for genphy"), which uses APIs removed in -next.] Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20250710201454.1280277-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions