Message-ID: <20130513045710.GA4440@S2101-09.ap.freescale.net>
Date:	Mon, 13 May 2013 12:57:13 +0800
From:	Shawn Guo <shawn.guo@...aro.org>
To:	Frank Li <Frank.Li@...escale.com>
CC:	<romieu@...zoreil.com>, <r.schwebel@...gutronix.de>,
	<davem@...emloft.net>, <l.stach@...gutronix.de>,
	<netdev@...r.kernel.org>, <festevam@...il.com>, <lznuaa@...il.com>
Subject: Re: [PATCH v5 1/1 net] net: fec: fix kernel oops when plug/unplug
 cable many times

Hi Frank,

On Wed, May 08, 2013 at 08:08:44AM +0800, Frank Li wrote:
> reproduce steps
>  1. flood ping from other machine
>  	ping -f -s 41000 IP
>  2. run below script
>     while [ 1 ]; do ethtool -s eth0 autoneg off;
>     sleep 3;ethtool -s eth0 autoneg on; sleep 4; done;
> 
> You can see oops in one hour.
> 
> The reason is fec_restart clear BD but NAPI may use it.
> The solution is disable NAPI and stop xmit when reset BD.
> disable NAPI may sleep, so fec_restart can't be call in
> atomic context.
> 
> Signed-off-by: Frank Li <Frank.Li@...escale.com>
> Reviewed-by: Lucas Stach <l.stach@...gutronix.de>
> Tested-by: Lucas Stach <l.stach@...gutronix.de>

The patch has landed on 3.10-rc1.  Seems that it introduces a lock
warning as below.  Turn on CONFIG_PROVE_LOCKING and you will be able
to see it.

Shawn

libphy: 2188000.ethernet:01 - Link is Up - 100/Full
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

=================================
[ INFO: inconsistent lock state ]
3.10.0-rc1+ #1 Not tainted
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[5]:HE1:SE0] takes:
 (_xmit_ETHER#2){+.?...}, at: [<8047a7b4>] sch_direct_xmit+0xb4/0x2fc
{SOFTIRQ-ON-W} state was registered at:
  [<80068a04>] mark_lock+0x150/0x6d0
  [<800695a8>] __lock_acquire+0x624/0x1ce0
  [<8006b16c>] lock_acquire+0x68/0x7c
  [<8054d1a4>] _raw_spin_lock+0x34/0x44
  [<80380788>] fec_restart+0x614/0x694
  [<803811f4>] fec_enet_adjust_link+0x84/0xbc
  [<8037d0ac>] phy_state_machine+0x184/0x39c
  [<8003dbfc>] process_one_work+0x1a4/0x42c
  [<8003e298>] worker_thread+0x138/0x3a8
  [<8004462c>] kthread+0xac/0xb8
  [<8000e688>] ret_from_fork+0x14/0x2c
irq event stamp: 9252
hardirqs last  enabled at (9252): [<8002bc08>] local_bh_enable_ip+0x84/0xec
hardirqs last disabled at (9251): [<8002bbc8>] local_bh_enable_ip+0x44/0xec
softirqs last  enabled at (9202): [<8002b8b0>] _local_bh_enable+0x14/0x18
softirqs last disabled at (9203): [<8002be80>] irq_exit+0xac/0xe8

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(_xmit_ETHER#2);
  <Interrupt>
    lock(_xmit_ETHER#2);

 *** DEADLOCK ***

4 locks held by swapper/0/0:
 #0:  (((&idev->mc_ifc_timer))){+.-...}, at: [<80031384>] call_timer_fn+0x0/0xf0
 #1:  (rcu_read_lock){.+.+..}, at: [<80501d58>] mld_sendpack+0x0/0x55c
 #2:  (rcu_read_lock_bh){.+....}, at: [<804e1e54>] ip6_finish_output2+0x44/0x748
 #3:  (rcu_read_lock_bh){.+....}, at: [<804641e4>] dev_queue_xmit+0x0/0x658

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc1+ #1
Backtrace:
[<80011ebc>] (dump_backtrace+0x0/0x10c) from [<8001205c>] (show_stack+0x18/0x1c)
 r6:80763fc8 r5:80763c08 r4:808a0358 r3:00000000
[<80012044>] (show_stack+0x0/0x1c) from [<80549188>] (dump_stack+0x20/0x28)
[<80549168>] (dump_stack+0x0/0x28) from [<805471f4>] (print_usage_bug+0x26c/0x2dc)
[<80546f88>] (print_usage_bug+0x0/0x2dc) from [<80068f0c>] (mark_lock+0x658/0x6d0)
[<800688b4>] (mark_lock+0x0/0x6d0) from [<80069560>] (__lock_acquire+0x5dc/0x1ce0)
[<80068f84>] (__lock_acquire+0x0/0x1ce0) from [<8006b16c>] (lock_acquire+0x68/0x7c)
[<8006b104>] (lock_acquire+0x0/0x7c) from [<8054d1a4>] (_raw_spin_lock+0x34/0x44)
 r7:00000000 r6:bf8e0800 r5:00000002 r4:bf8b5440
[<8054d170>] (_raw_spin_lock+0x0/0x44) from [<8047a7b4>] (sch_direct_xmit+0xb4/0x2fc)
 r5:bf8b5400 r4:bfbe7600
[<8047a700>] (sch_direct_xmit+0x0/0x2fc) from [<80464474>] (dev_queue_xmit+0x290/0x658)
[<804641e4>] (dev_queue_xmit+0x0/0x658) from [<8046caf4>] (neigh_resolve_output+0x114/0x218)
[<8046c9e0>] (neigh_resolve_output+0x0/0x218) from [<804e21d8>] (ip6_finish_output2+0x3c8/0x748)
[<804e1e10>] (ip6_finish_output2+0x0/0x748) from [<804e5798>] (ip6_finish_output+0xb0/0x1dc)
[<804e56e8>] (ip6_finish_output+0x0/0x1dc) from [<804e5964>] (ip6_output+0xa0/0x244)
 r5:bf8e0800 r4:bf022480
[<804e58c4>] (ip6_output+0x0/0x244) from [<805021f0>] (mld_sendpack+0x498/0x55c)
 r7:00000000 r6:bfbe5400 r5:0000004c r4:bf022480
[<80501d58>] (mld_sendpack+0x0/0x55c) from [<805028f4>] (mld_ifc_timer_expire+0x1d4/0x2b0)
[<80502720>] (mld_ifc_timer_expire+0x0/0x2b0) from [<800313f8>] (call_timer_fn+0x74/0xf0)
[<80031384>] (call_timer_fn+0x0/0xf0) from [<80031668>] (run_timer_softirq+0x1f4/0x210)
 r8:807e5d70 r7:00000000 r6:8075a0c0 r5:807e5540 r4:80759e38
[<80031474>] (run_timer_softirq+0x0/0x210) from [<8002b9b4>] (__do_softirq+0x100/0x1f4)
[<8002b8b4>] (__do_softirq+0x0/0x1f4) from [<8002be80>] (irq_exit+0xac/0xe8)
[<8002bdd4>] (irq_exit+0x0/0xe8) from [<8000eef8>] (handle_IRQ+0x58/0xb4)
 r4:80760c78 r3:00000220
[<8000eea0>] (handle_IRQ+0x0/0xb4) from [<80008604>] (gic_handle_irq+0x30/0x64)
 r8:807a2f6d r7:f4000100 r6:80759f18 r5:80760dbc r4:f400010c
r3:00000000
[<800085d4>] (gic_handle_irq+0x0/0x64) from [<8000e124>] (__irq_svc+0x44/0x5c)
Exception stack(0x80759f18 to 0x80759f60)
9f00:                                                       00000001 00000001
9f20: 00000000 80763c08 80758000 00000000 807a2f6d 00000001 807a2f6d 8055042c
9f40: 8076092c 80759f6c 80759f30 80759f60 8006badc 8000f2a4 20000113 ffffffff
 r7:80759f4c r6:ffffffff r5:20000113 r4:8000f2a4
[<8000f27c>] (arch_cpu_idle+0x0/0x44) from [<8005badc>] (cpu_startup_entry+0x74/0x160)
[<8005ba68>] (cpu_startup_entry+0x0/0x160) from [<80540e34>] (rest_init+0xb0/0xd8)
 r7:81512400
[<80540d84>] (rest_init+0x0/0xd8) from [<80712848>] (start_kernel+0x2c4/0x31c)
 r6:807493e8 r5:807a3080 r4:80760990
[<80712584>] (start_kernel+0x0/0x31c) from [<10008074>] (0x10008074)
 r7:80764fec r6:807493e4 r5:807608d0 r4:10c53c7d

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

Powered by blists - more mailing lists