Skip to contentSkip to conversation

possible deadlock in tulip driver

PATCH In review Denis V. Lunev 3 participants 3 messages Jul 24, 2007 – Jul 31, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 possible deadlock in tulip driver

Calling flush_scheduled_work() may deadlock if called under rtnl_lock (from dev->stop) as linkwatch_event() may be on the workqueue and it will try to get the rtnl_lock

---

 tulip_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/tulip/tulip_core.c renamed from drivers/net/tulip/tulip_core.c.tulip +2 -2
@@ -726,8 +726,6 @@ static void tulip_down (struct net_devic
 	void __iomem *ioaddr = tp->base_addr;
 	unsigned long flags;
 
-	flush_scheduled_work();
-
 	del_timer_sync (&tp->timer);
 #ifdef CONFIG_TULIP_NAPI
 	del_timer_sync (&tp->oom_timer);
@@ -1788,6 +1786,8 @@ static void __devexit tulip_remove_one (
 	if (!dev)
 		return;
 
+	flush_scheduled_work();
+
 	tp = netdev_priv(dev);
 	unregister_netdev(dev);
 	pci_free_consistent (pdev,
#1 lore raw

(No longer maintainer, btw.)

What situation have you tested this under? Thanks,

-VAL

Quoted 34 lines · Denis V. Lunev

Calling flush_scheduled_work() may deadlock if called under rtnl_lock (from dev->stop) as linkwatch_event() may be on the workqueue and it will try to get the rtnl_lock

---

 tulip_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/tulip/tulip_core.c renamed from drivers/net/tulip/tulip_core.c.tulip +2 -3
@@ -726,8 +726,6 @@ static void tulip_down (struct net_devic
 	void __iomem *ioaddr = tp->base_addr;
 	unsigned long flags;
 
-	flush_scheduled_work();
-
 	del_timer_sync (&tp->timer);
 #ifdef CONFIG_TULIP_NAPI
 	del_timer_sync (&tp->oom_timer);
@@ -1788,6 +1786,8 @@ static void __devexit tulip_remove_one (
 	if (!dev)
 		return;
 
+	flush_scheduled_work();
+
 	tp = netdev_priv(dev);
 	unregister_netdev(dev);
 	pci_free_consistent (pdev,
-

To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw

Manual code check. The similar fixes are present in almost all drivers, f.e. tg3 one. I have an unrelated deadlock with rtnl.

Regards,
Den

Quoted 42 lines · Valerie Henson

(No longer maintainer, btw.)

What situation have you tested this under? Thanks,

-VAL

Quoted 34 lines · Denis V. Lunev

Calling flush_scheduled_work() may deadlock if called under rtnl_lock (from dev->stop) as linkwatch_event() may be on the workqueue and it will try to get the rtnl_lock

---

 tulip_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/tulip/tulip_core.c renamed from drivers/net/tulip/tulip_core.c.tulip +2 -3
@@ -726,8 +726,6 @@ static void tulip_down (struct net_devic
 	void __iomem *ioaddr = tp->base_addr;
 	unsigned long flags;
 
-	flush_scheduled_work();
-
 	del_timer_sync (&tp->timer);
 #ifdef CONFIG_TULIP_NAPI
 	del_timer_sync (&tp->oom_timer);
@@ -1788,6 +1786,8 @@ static void __devexit tulip_remove_one (
 	if (!dev)
 		return;
 
+	flush_scheduled_work();
+
 	tp = netdev_priv(dev);
 	unregister_netdev(dev);
 	pci_free_consistent (pdev,
-

To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html