Thread (1 message) 1 message, 1 author, 3d ago

RE: [PATCH v5 net-next 4/9] net: dsa: netc: tie setup resources and reset to DSA setup/teardown

From: Wei Fang (OSS) <hidden>
Date: 2026-10-14 02:24:03
Also in: imx, sashiko-reviews

quoted
+static int netc_switch_reset(struct netc_switch *priv)
+{
+	if (priv->in_probe)
+		return pci_reset_function_locked(priv->pdev);
[Severity: High]
Can a concurrent thread execute this path without holding the PCI device
lock?

In a multi-switch DSA tree, priv->in_probe is set to true during
netc_switch_probe(). The thread then calls dsa_register_switch(), which
internally acquires and releases dsa2_mutex. If the DSA tree is incomplete,
it returns, and the thread can be preempted before executing
priv->in_probe = false.

Concurrently, a second thread could probe the second switch, complete the
tree, acquire dsa2_mutex, and call dsa_tree_setup_switches(). This invokes
netc_setup() for the first switch. Observing priv->in_probe == true, the
second thread would call pci_reset_function_locked() on the first switch's
PCI device, despite not holding its device lock.
Yes, there is a potential issue, I will fix it
quoted
+
+	return pci_reset_function(priv->pdev);
[Severity: High]
Does this introduce an AB-BA deadlock between the PCI device lock and
dsa2_mutex?

When a multi-switch DSA tree is set up, netc_setup() can be called for an
already-probed switch. In this case, priv->in_probe is false, and
netc_switch_reset() calls pci_reset_function(), which acquires the PCI
device lock. However, netc_setup() is invoked by the DSA core with the
global dsa2_mutex held.

Conversely, when a switch is unbound (e.g. via sysfs), the driver core first
acquires the switch's device lock and then calls the driver's remove
callback. The netc_switch_remove() function calls dsa_unregister_switch(),
which attempts to acquire dsa2_mutex:

net/dsa/dsa.c:dsa_unregister_switch() {
    ...
    mutex_lock(&dsa2_mutex);
    dsa_switch_remove(ds);
    mutex_unlock(&dsa2_mutex);
    ...
}

If Thread 1 is unbinding Switch A (holding the device lock for A and waiting
for dsa2_mutex) while Thread 2 is probing Switch B (holding dsa2_mutex and
calling pci_reset_function(A) inside netc_setup(A)), the system could
deadlock.
--
pw-bot: cr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help