linux/drivers/net/dsa
Alexander Sverdlin 105d29fa8d net: dsa: lan9303: consequently nested-lock physical MDIO
commit 5a22fbcc10 upstream.

When LAN9303 is MDIO-connected two callchains exist into
mdio->bus->write():

1. switch ports 1&2 ("physical" PHYs):

virtual (switch-internal) MDIO bus (lan9303_switch_ops->phy_{read|write})->
  lan9303_mdio_phy_{read|write} -> mdiobus_{read|write}_nested

2. LAN9303 virtual PHY:

virtual MDIO bus (lan9303_phy_{read|write}) ->
  lan9303_virt_phy_reg_{read|write} -> regmap -> lan9303_mdio_{read|write}

If the latter functions just take
mutex_lock(&sw_dev->device->bus->mdio_lock) it triggers a LOCKDEP
false-positive splat. It's false-positive because the first
mdio_lock in the second callchain above belongs to virtual MDIO bus, the
second mdio_lock belongs to physical MDIO bus.

Consequent annotation in lan9303_mdio_{read|write} as nested lock
(similar to lan9303_mdio_phy_{read|write}, it's the same physical MDIO bus)
prevents the following splat:

WARNING: possible circular locking dependency detected
5.15.71 #1 Not tainted
------------------------------------------------------
kworker/u4:3/609 is trying to acquire lock:
ffff000011531c68 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}, at: regmap_lock_mutex
but task is already holding lock:
ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&bus->mdio_lock){+.+.}-{3:3}:
       lock_acquire
       __mutex_lock
       mutex_lock_nested
       lan9303_mdio_read
       _regmap_read
       regmap_read
       lan9303_probe
       lan9303_mdio_probe
       mdio_probe
       really_probe
       __driver_probe_device
       driver_probe_device
       __device_attach_driver
       bus_for_each_drv
       __device_attach
       device_initial_probe
       bus_probe_device
       deferred_probe_work_func
       process_one_work
       worker_thread
       kthread
       ret_from_fork
-> #0 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}:
       __lock_acquire
       lock_acquire.part.0
       lock_acquire
       __mutex_lock
       mutex_lock_nested
       regmap_lock_mutex
       regmap_read
       lan9303_phy_read
       dsa_slave_phy_read
       __mdiobus_read
       mdiobus_read
       get_phy_device
       mdiobus_scan
       __mdiobus_register
       dsa_register_switch
       lan9303_probe
       lan9303_mdio_probe
       mdio_probe
       really_probe
       __driver_probe_device
       driver_probe_device
       __device_attach_driver
       bus_for_each_drv
       __device_attach
       device_initial_probe
       bus_probe_device
       deferred_probe_work_func
       process_one_work
       worker_thread
       kthread
       ret_from_fork
other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(&bus->mdio_lock);
                               lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
                               lock(&bus->mdio_lock);
  lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
*** DEADLOCK ***
5 locks held by kworker/u4:3/609:
 #0: ffff000002842938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work
 #1: ffff80000bacbd60 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work
 #2: ffff000007645178 (&dev->mutex){....}-{3:3}, at: __device_attach
 #3: ffff8000096e6e78 (dsa2_mutex){+.+.}-{3:3}, at: dsa_register_switch
 #4: ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
stack backtrace:
CPU: 1 PID: 609 Comm: kworker/u4:3 Not tainted 5.15.71 #1
Workqueue: events_unbound deferred_probe_work_func
Call trace:
 dump_backtrace
 show_stack
 dump_stack_lvl
 dump_stack
 print_circular_bug
 check_noncircular
 __lock_acquire
 lock_acquire.part.0
 lock_acquire
 __mutex_lock
 mutex_lock_nested
 regmap_lock_mutex
 regmap_read
 lan9303_phy_read
 dsa_slave_phy_read
 __mdiobus_read
 mdiobus_read
 get_phy_device
 mdiobus_scan
 __mdiobus_register
 dsa_register_switch
 lan9303_probe
 lan9303_mdio_probe
...

Cc: stable@vger.kernel.org
Fixes: dc70058315 ("net: dsa: LAN9303: add MDIO managed mode support")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20231027065741.534971-1-alexander.sverdlin@siemens.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
History 2023-11-28 17:07:18 +00:00
..
b53 net: dsa: b53: mmap: add phy ops 2023-04-26 14:28:36 +02:00
hirschmann net: dsa: hellcreek: Offload per-tc max SDU from tc-taprio 2022-09-29 18:52:06 -07:00
microchip net: dsa: microchip: KSZ9477 register regmap alignment to 32 bit boundaries 2023-09-13 09:42:23 +02:00
mv88e6xxx net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent 2023-10-10 22:00:42 +02:00
ocelot net: dsa: felix: fix oversize frame dropping for always closed tc-taprio gates 2023-08-30 16:11:00 +02:00
qca net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames 2023-10-19 23:08:52 +02:00
realtek net: dsa: realtek: fix out-of-bounds access 2023-04-06 12:10:44 +02:00
sja1105 net: dsa: sja1105: block FDB accesses that are concurrent with a switch reset 2023-09-19 12:28:09 +02:00
xrs700x * 'remove' callback converted to return void. Big change with trivial 2022-10-04 18:54:33 -07:00
bcm_sf2.c net: dsa: bcm_sf2: Fix possible memory leak in bcm_sf2_mdio_register() 2023-10-25 12:03:07 +02:00
bcm_sf2.h net: dsa: bcm_sf2: refactor LED regs access 2021-12-30 17:28:32 -08:00
bcm_sf2_cfp.c net: dsa: introduce dsa_port_get_master() 2022-09-20 10:32:35 +02:00
bcm_sf2_regs.h net: dsa: bcm_sf2: refactor LED regs access 2021-12-30 17:28:32 -08:00
dsa_loop.c net: dsa: Fix possible memory leaks in dsa_loop_init() 2022-10-28 10:32:59 +01:00
dsa_loop.h License cleanup: add SPDX GPL-2.0 license identifier to files with no license 2017-11-02 11:10:55 +01:00
dsa_loop_bdinfo.c treewide: Add SPDX license identifier for more missed files 2019-05-21 10:50:45 +02:00
Kconfig net: dsa: LAN9303: Add basic support for LAN9354 2022-09-07 11:06:04 +01:00
lan9303-core.c net: dsa: lan9303: allow vid != 0 in port_fdb_{add|del} methods 2023-06-14 11:15:16 +02:00
lan9303.h net: dsa: be compatible with masters which unregister on shutdown 2021-09-19 12:08:37 +01:00
lan9303_i2c.c * 'remove' callback converted to return void. Big change with trivial 2022-10-04 18:54:33 -07:00
lan9303_mdio.c net: dsa: lan9303: consequently nested-lock physical MDIO 2023-11-28 17:07:18 +00:00
lantiq_gswip.c net: dsa: lantiq_gswip: remove unnecessary platform_set_drvdata() 2022-09-22 19:30:36 -07:00
lantiq_pce.h net: dsa: Use the correct style for SPDX License Identifier 2019-09-22 15:25:08 -07:00
Makefile net: dsa: qca8k: move driver to qca dir 2022-07-15 11:57:13 +01:00
mt7530.c net: dsa: mt7530: fix handling of 802.1X PAE frames 2023-08-30 16:11:01 +02:00
mt7530.h net: dsa: mt7530: fix handling of 802.1X PAE frames 2023-08-30 16:11:01 +02:00
mv88e6060.c net: dsa: mv88e6060: remove unnecessary dev_set_drvdata() 2022-09-22 19:30:37 -07:00
mv88e6060.h treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 2019-05-30 11:26:32 -07:00
rzn1_a5psw.c net: dsa: rzn1-a5psw: disable learning for standalone ports 2023-05-24 17:32:44 +01:00
rzn1_a5psw.h net: dsa: rzn1-a5psw: fix STP states handling 2023-05-24 17:32:44 +01:00
vitesse-vsc73xx-core.c net: dsa: vsc73xx: fix MTU configuration 2023-07-19 16:22:03 +02:00
vitesse-vsc73xx-platform.c net: dsa: vitesse-vsc73xx: remove unnecessary set_drvdata() 2022-09-22 19:30:39 -07:00
vitesse-vsc73xx-spi.c net: dsa: vitesse-vsc73xx: remove unnecessary set_drvdata() 2022-09-22 19:30:39 -07:00
vitesse-vsc73xx.h net: dsa: vsc73xxx: Make vsc73xx_remove() return void 2021-11-15 13:15:07 +00:00