From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: mv643xx_eth.c lockdep violation Date: Sat, 27 Apr 2013 22:55:30 +0100 Message-ID: <20130427215530.GI14496@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Lennert Buytenhek , netdev@vger.kernel.org Return-path: Received: from caramon.arm.linux.org.uk ([78.32.30.218]:40101 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753425Ab3D0Vzi (ORCPT ); Sat, 27 Apr 2013 17:55:38 -0400 Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-ID: On shutdown, the mv643xx_eth driver hits the following problem when it is taken down. I've been noticing this for a number of kernel versions now that I've enabled lockdep, so it's not a new problem. ================================= [ INFO: inconsistent lock state ] 3.8.0+ #303 Not tainted --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. NetworkManager/3449 [HC0[0]:SC0[0]:HE1:SE1] takes: (_xmit_ETHER#2){+.?...}, at: [] txq_reclaim+0x60/0x230 {IN-SOFTIRQ-W} state was registered at: [] mark_irqflags+0xf8/0x1c4 [] __lock_acquire+0x458/0x9a4 [] lock_acquire+0x60/0x74 [] _raw_spin_lock+0x40/0x50 [] sch_direct_xmit+0xa4/0x2e4 [] dev_queue_xmit+0x174/0x508 [] ip6_finish_output2+0xd0/0x3c4 [] mld_sendpack+0x190/0x368 [] mld_ifc_timer_expire+0xc/0x58 [] call_timer_fn+0x6c/0xe0 [] run_timer_softirq+0x1d8/0x210 [] __do_softirq+0xe0/0x1b4 [] irq_exit+0x64/0x6c [] handle_IRQ+0x34/0x84 [] __irq_usr+0x30/0x80 irq event stamp: 160603 hardirqs last enabled at (160603): [] kfree+0xa8/0xe8 hardirqs last disabled at (160602): [] kfree+0x1c/0xe8 softirqs last enabled at (160304): [] mib_counters_update+0x5ec/0x60c softirqs last disabled at (160302): [] _raw_spin_lock_bh+0x14/0x54 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** DEADLOCK *** 1 lock held by NetworkManager/3449: #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0xc/0x24 stack backtrace: [] (unwind_backtrace+0x0/0xf8) from [] (print_usage_bug+0x150/0x1d4) [] (print_usage_bug+0x150/0x1d4) from [] (mark_lock_irq+0x248/0x290) [] (mark_lock_irq+0x248/0x290) from [] (mark_lock+0x158/0x404) [] (mark_lock+0x158/0x404) from [] (mark_irqflags+0x138/0x1c4) [] (mark_irqflags+0x138/0x1c4) from [] (__lock_acquire+0x458/0x9a4) [] (__lock_acquire+0x458/0x9a4) from [] (lock_acquire+0x60/0x74) [] (lock_acquire+0x60/0x74) from [] (_raw_spin_lock+0x40/0x50) [] (_raw_spin_lock+0x40/0x50) from [] (txq_reclaim+0x60/0x230) [] (txq_reclaim+0x60/0x230) from [] (txq_deinit+0x24/0xcc) [] (txq_deinit+0x24/0xcc) from [] (mv643xx_eth_stop+0x1a8/0x1bc) [] (mv643xx_eth_stop+0x1a8/0x1bc) from [] (__dev_close_many+0x88/0xcc) [] (__dev_close_many+0x88/0xcc) from [] (__dev_close+0x28/0x3c) [] (__dev_close+0x28/0x3c) from [] (__dev_change_flags+0x7c/0x134) [] (__dev_change_flags+0x7c/0x134) from [] (dev_change_flags+0x10/0x48) [] (dev_change_flags+0x10/0x48) from [] (do_setlink+0x1a0/0x730) [] (do_setlink+0x1a0/0x730) from [] (rtnl_newlink+0x304/0x4b0) [] (rtnl_newlink+0x304/0x4b0) from [] (rtnetlink_rcv_msg+0x25c/0x2a0) [] (rtnetlink_rcv_msg+0x25c/0x2a0) from [] (netlink_rcv_skb+0xbc/0xd8) [] (netlink_rcv_skb+0xbc/0xd8) from [] (rtnetlink_rcv+0x1c/0x24) [] (rtnetlink_rcv+0x1c/0x24) from [] (netlink_unicast_kernel+0x88/0xd4) [] (netlink_unicast_kernel+0x88/0xd4) from [] (netlink_unicast+0x138/0x180) [] (netlink_unicast+0x138/0x180) from [] (netlink_sendmsg+0x208/0x32c) [] (netlink_sendmsg+0x208/0x32c) from [] (sock_sendmsg+0x84/0xa4) [] (sock_sendmsg+0x84/0xa4) from [] (__sys_sendmsg+0x2ac/0x2c4) [] (__sys_sendmsg+0x2ac/0x2c4) from [] (sys_sendmsg+0x3c/0x68) [] (sys_sendmsg+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c) It seems that txq_reclaim() takes the netif tx lock: __netif_tx_lock(nq, smp_processor_id()); in a context outside of softirq context, and thus is susceptible to deadlock should an interrupt occur. Maybe the call to txq_reclaim() in txq_deinit() should disable local IRQs? Someone who knows this driver needs to look at this.