possible deadlock in tulip driver
Subsystems (2)
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_devicvoid __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,
(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 underrtnl_lock(fromdev->stop) aslinkwatch_event()may be on the workqueue and it will try to get thertnl_lockSigned-off-by Denis V. Lunev <[email protected]>---
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_devicvoid __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
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 underrtnl_lock(fromdev->stop) aslinkwatch_event()may be on the workqueue and it will try to get thertnl_lockSigned-off-by Denis V. Lunev <[email protected]>---
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_devicvoid __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