fec: Fix inconsistent lock state
fec_restart() runs in softirq context and we should use the netif_tx_lock_bh/netif_tx_unlock_bh() variants to avoid the following warning that happens since commit 54309fa6 ("net: fec: fix kernel oops when plug/unplug cable many times"): [ 9.753168] ================================= [ 9.757540] [ INFO: inconsistent lock state ] [ 9.761921] 3.10.0-rc1-next-20130514 #13 Not tainted [ 9.766897] --------------------------------- [ 9.771264] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 9.777288] swapper/0 [HC0[0]:SC1[3]:HE1:SE0] takes: [ 9.782261] (_xmit_ETHER#2){+.?...}, at: [<c03c24a4>] sch_direct_xmit+0xa0/0x2d4 [ 9.789879] {SOFTIRQ-ON-W} state was registered at: [ 9.794769] [<c0059c60>] __lock_acquire+0x528/0x1bc0 [ 9.799953] [<c005b838>] lock_acquire+0xa0/0x108 [ 9.804780] [<c0441320>] _raw_spin_lock+0x28/0x38 [ 9.809702] [<c02f9fc8>] fec_restart+0x5d0/0x664 [ 9.814542] [<c02fa738>] fec_enet_adjust_link+0xa8/0xc0 [ 9.819978] [<c02f7a28>] phy_state_machine+0x2fc/0x370 [ 9.825323] [<c0035ee0>] process_one_work+0x1c0/0x4a0 [ 9.830589] [<c0036594>] worker_thread+0x138/0x394 [ 9.835587] [<c003c620>] kthread+0xa4/0xb0 [ 9.839890] [<c000e820>] ret_from_fork+0x14/0x34 [ 9.844728] irq event stamp: 185984 [ 9.848226] hardirqs last enabled at (185984): [<c00232b0>] local_bh_enable_ip+0x84/0xf0 [ 9.856450] hardirqs last disabled at (185983): [<c0023270>] local_bh_enable_ip+0x44/0xf0 [ 9.864667] softirqs last enabled at (185966): [<c0023470>] irq_enter+0x64/0x68 [ 9.872099] softirqs last disabled at (185967): [<c0023510>] irq_exit+0x9c/0xd8 [ 9.879440] [ 9.879440] other info that might help us debug this: [ 9.885981] Possible unsafe locking scenario: [ 9.885981] [ 9.891912] CPU0 [ 9.894364] ---- [ 9.896814] lock(_xmit_ETHER#2); [ 9.900259] <Interrupt> [ 9.902884] lock(_xmit_ETHER#2); [ 9.906500] [ 9.906500] *** DEADLOCK *** Reported-by: Shawn Guo <shawn.guo@linaro.org> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment