* Re: batman-adv: gpf in batadv_slide_own_bcast_window
From: Antonio Quartulli @ 2013-02-22 17:06 UTC (permalink / raw)
To: Sasha Levin
Cc: Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev, linux-kernel@vger.kernel.org, Dave Jones
In-Reply-To: <5127A2AF.9030502@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]
Hi Sasha and thank you very much for reporting this issue.
IIRC this is similar to a bug you already reported in the past.
This bug should be the result of a race condition batman-adv has in the
hard-interface handling code (this is why it has been triggered while removing
eth0).
Now that the rtnl-deadlock has been solved I think we can try to further
investigate on this bug and try to find a solution..though it will not be easy
as it probably requires another lock to protect the hard-interface during this
operations.
If you have any fix proposal feel free to contribute!
Cheers,
On Fri, Feb 22, 2013 at 11:54:07AM -0500, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next kernel
> I've stumbled on the following:
>
> [ 3148.615130] batman_adv: <98>\<AE><A4><C7>^?: Removing interface: eth0
> [ 3148.991938] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 3148.993736] Dumping ftrace buffer:
> [ 3148.997554] (ftrace buffer empty)
> [ 3148.998426] Modules linked in:
> [ 3148.999135] CPU 3
> [ 3148.999606] Pid: 6, comm: kworker/u:0 Tainted: G W 3.8.0-next-20130222-sasha-00038-gba27e20-dirty #11
> [ 3149.001223] RIP: 0010:[<ffffffff83d217d8>] [<ffffffff83d217d8>] batadv_slide_own_bcast_window+0xb8/0x2b0
> [ 3149.001223] RSP: 0018:ffff8800b9f4fc58 EFLAGS: 00010246
> [ 3149.001223] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> [ 3149.001223] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> [ 3149.001223] RBP: ffff8800b9f4fcb8 R08: 0000000000000002 R09: ffff8800b9f63950
> [ 3149.001223] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800abad2238
> [ 3149.001223] R13: 6b6b6b6b6b6b865b R14: ffff88004c13cda0 R15: 0000000000000001
> [ 3149.001223] FS: 0000000000000000(0000) GS:ffff8800bbc00000(0000) knlGS:0000000000000000
> [ 3149.001223] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3149.001223] CR2: 00007f006711f1d0 CR3: 000000008258e000 CR4: 00000000000406e0
> [ 3149.001223] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3149.001223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 3149.001223] Process kworker/u:0 (pid: 6, threadinfo ffff8800b9f4e000, task ffff8800b9f63000)
> [ 3149.001223] Stack:
> [ 3149.001223] ffffffff83d21760 ffff8800b9f63000 ffff8800abad2238 0000000000000000
> [ 3149.001223] ffff880068f6c438 0000035e00000001 ffff8800b9f4fc98 0000000000000000
> [ 3149.001223] ffff8800abad2238 ffff88004c13c2a0 ffff88004c13cda0 0000000000000001
> [ 3149.001223] Call Trace:
> [ 3149.001223] [<ffffffff83d21760>] ? batadv_slide_own_bcast_window+0x40/0x2b0
> [ 3149.001223] [<ffffffff83d10ee4>] batadv_iv_ogm_schedule+0x254/0x300
> [ 3149.001223] [<ffffffff83d10c90>] ? batadv_iv_ogm_queue_add+0x710/0x710
> [ 3149.001223] [<ffffffff811178bf>] ? local_bh_enable_ip+0xef/0x150
> [ 3149.001223] [<ffffffff83d25a15>] batadv_send_outstanding_bat_ogm_packet+0xc5/0xf0
> [ 3149.001223] [<ffffffff81133ce6>] process_one_work+0x366/0x6a0
> [ 3149.001223] [<ffffffff81133ba8>] ? process_one_work+0x228/0x6a0
> [ 3149.001223] [<ffffffff811345a8>] worker_thread+0x238/0x370
> [ 3149.001223] [<ffffffff81134370>] ? rescuer_thread+0x310/0x310
> [ 3149.001223] [<ffffffff8113eb73>] kthread+0xe3/0xf0
> [ 3149.001223] [<ffffffff8113ea90>] ? flush_kthread_work+0x1f0/0x1f0
> [ 3149.001223] [<ffffffff83dc203c>] ret_from_fork+0x7c/0xb0
> [ 3149.001223] [<ffffffff8113ea90>] ? flush_kthread_work+0x1f0/0x1f0
> [ 3149.001223] Code: 31 4b fd 85 c0 74 24 48 c7 c2 50 cd bd 84 be 02 03 00 00 48 c7 c7 b4 da bd 84 c6 05 14 ab 16 02 01 e8 ed 16
> 46 fd 0f 1f 44 00 00 <49> 8b 55 00 48 89 55 b8 e8 0b 55 41 fd 85 c0 74 37 80 3d ee aa
> [ 3149.001223] RIP [<ffffffff83d217d8>] batadv_slide_own_bcast_window+0xb8/0x2b0
> [ 3149.001223] RSP <ffff8800b9f4fc58>
> [ 3149.105631] ---[ end trace ba69e369627c73e7 ]---
>
> Rip points to:
>
> for (i = 0; i < hash->size; i++) {
> head = &hash->table[i];
>
> rcu_read_lock();
> hlist_for_each_entry_rcu(orig_node, head, hash_entry) { <--- here
> spin_lock_bh(&orig_node->ogm_cnt_lock);
> word_index = hard_iface->if_num * BATADV_NUM_WORDS;
> word = &(orig_node->bcast_own[word_index]);
>
>
> Thanks,
> Sasha
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* lockdep trace from sockstat_seq_show
From: Dave Jones @ 2013-02-22 17:13 UTC (permalink / raw)
To: Linux Kernel; +Cc: netdev
Just hit this on Linus' current tree.
[ 1789.629729] =========================================================
[ 1789.629731] [ INFO: possible irq lock inversion dependency detected ]
[ 1789.629736] 3.8.0+ #76 Not tainted
[ 1789.629738] ---------------------------------------------------------
[ 1789.629742] swapper/0/0 just changed the state of lock:
[ 1789.629744] blocked: (&(&q->lock)->rlock){+.-...}, instance: ffff88006c24da58, at: [<ffffffff8151c6d8>] ip_expire+0x28/0x220
[ 1789.629762] but this lock took another, SOFTIRQ-unsafe lock in the past:
[ 1789.629765] (key#15){+.+...}
and interrupts could create inverse lock ordering between them.
[ 1789.629772]
other info that might help us debug this:
[ 1789.629775] Possible interrupt unsafe locking scenario:
[ 1789.629778] CPU0 CPU1
[ 1789.629780] ---- ----
[ 1789.629782] lock(key#15);
[ 1789.629788] local_irq_disable();
[ 1789.629790] lock(&(&q->lock)->rlock);
[ 1789.629794] lock(key#15);
[ 1789.629799] <Interrupt>
[ 1789.629801] lock(&(&q->lock)->rlock);
[ 1789.629805]
*** DEADLOCK ***
[ 1789.629809] 1 lock on stack by swapper/0/0:
[ 1789.629812] #0: blocked: (((&q->timer))){+.-...}, instance: ffff880119803dd0, at: [<ffffffff81056ad5>] call_timer_fn+0x5/0x1f0
[ 1789.629826]
the shortest dependencies between 2nd lock and 1st lock:
[ 1789.629844] -> (key#15){+.+...} ops: 132 {
[ 1789.629854] HARDIRQ-ON-W at:
[ 1789.629857] [<ffffffff810ade4a>] __lock_acquire+0x64a/0x1cb0
[ 1789.629865] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.629871] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.629878] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
[ 1789.629885] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
[ 1789.629891] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
[ 1789.629898] [<ffffffff811b744c>] seq_read+0xcc/0x460
[ 1789.629904] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
[ 1789.629910] [<ffffffff81193e5c>] vfs_read+0xac/0x180
[ 1789.629916] [<ffffffff81193f85>] sys_read+0x55/0xa0
[ 1789.629920] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
[ 1789.629926] SOFTIRQ-ON-W at:
[ 1789.629929] [<ffffffff810ade86>] __lock_acquire+0x686/0x1cb0
[ 1789.629935] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.629941] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.629946] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
[ 1789.629951] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
[ 1789.629957] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
[ 1789.629963] [<ffffffff811b744c>] seq_read+0xcc/0x460
[ 1789.629968] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
[ 1789.629973] [<ffffffff81193e5c>] vfs_read+0xac/0x180
[ 1789.629977] [<ffffffff81193f85>] sys_read+0x55/0xa0
[ 1789.629981] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
[ 1789.629986] INITIAL USE at:
[ 1789.629989] [<ffffffff810adb0d>] __lock_acquire+0x30d/0x1cb0
[ 1789.629995] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630001] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630006] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
[ 1789.630012] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
[ 1789.630017] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
[ 1789.630023] [<ffffffff811b744c>] seq_read+0xcc/0x460
[ 1789.630028] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
[ 1789.630033] [<ffffffff81193e5c>] vfs_read+0xac/0x180
[ 1789.630038] [<ffffffff81193f85>] sys_read+0x55/0xa0
[ 1789.630042] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
[ 1789.630047] }
[ 1789.630049] ... key at: [<ffffffff829fb1e8>] __key.23045+0x0/0x8
[ 1789.630055] ... acquired at:
[ 1789.630057] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630063] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630068] [<ffffffff81308b74>] __percpu_counter_add+0x54/0xc0
[ 1789.630073] [<ffffffff8151bea4>] ip_defrag+0x6e4/0xd40
[ 1789.630079] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
[ 1789.630084] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
[ 1789.630090] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
[ 1789.630095] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
[ 1789.630099] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
[ 1789.630103] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
[ 1789.630132] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
[ 1789.630152] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
[ 1789.630170] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
[ 1789.630188] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
[ 1789.630201] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
[ 1789.630212] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
[ 1789.630225] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
[ 1789.630232] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
[ 1789.630237] [<ffffffff8106c5ed>] kthread+0xed/0x100
[ 1789.630243] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
[ 1789.630251] -> (&(&q->lock)->rlock){+.-...} ops: 18 {
[ 1789.630260] HARDIRQ-ON-W at:
[ 1789.630264] [<ffffffff810ade4a>] __lock_acquire+0x64a/0x1cb0
[ 1789.630270] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630276] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630281] [<ffffffff8151b8df>] ip_defrag+0x11f/0xd40
[ 1789.630287] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
[ 1789.630292] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
[ 1789.630297] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
[ 1789.630301] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
[ 1789.630305] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
[ 1789.630310] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
[ 1789.630330] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
[ 1789.630348] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
[ 1789.630365] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
[ 1789.630382] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
[ 1789.630392] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
[ 1789.630402] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
[ 1789.630412] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
[ 1789.630418] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
[ 1789.630423] [<ffffffff8106c5ed>] kthread+0xed/0x100
[ 1789.630429] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
[ 1789.630434] IN-SOFTIRQ-W at:
[ 1789.630437] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
[ 1789.630444] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630449] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630454] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
[ 1789.630460] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
[ 1789.630466] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
[ 1789.630471] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
[ 1789.630478] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
[ 1789.630483] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
[ 1789.630488] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
[ 1789.630494] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
[ 1789.630499] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
[ 1789.630504] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
[ 1789.630510] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
[ 1789.630516] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
[ 1789.630521] [<ffffffff81591321>] rest_init+0xc1/0xd0
[ 1789.630528] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
[ 1789.630536] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
[ 1789.630541] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
[ 1789.630547] INITIAL USE at:
[ 1789.630550] [<ffffffff810adb0d>] __lock_acquire+0x30d/0x1cb0
[ 1789.630556] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630562] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630566] [<ffffffff8151b8df>] ip_defrag+0x11f/0xd40
[ 1789.630572] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
[ 1789.630577] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
[ 1789.630583] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
[ 1789.630587] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
[ 1789.630591] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
[ 1789.630595] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
[ 1789.630615] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
[ 1789.630631] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
[ 1789.630647] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
[ 1789.630664] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
[ 1789.630674] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
[ 1789.630684] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
[ 1789.630694] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
[ 1789.630700] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
[ 1789.630705] [<ffffffff8106c5ed>] kthread+0xed/0x100
[ 1789.630711] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
[ 1789.630716] }
[ 1789.630718] ... key at: [<ffffffff829fb1f8>] __key.32665+0x0/0x8
[ 1789.630723] ... acquired at:
[ 1789.630726] [<ffffffff810ace86>] check_usage_forwards+0x136/0x140
[ 1789.630732] [<ffffffff810ad6c6>] mark_lock+0x176/0x2b0
[ 1789.630737] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
[ 1789.630743] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630748] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630753] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
[ 1789.630759] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
[ 1789.630765] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
[ 1789.630770] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
[ 1789.630776] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
[ 1789.630781] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
[ 1789.630785] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
[ 1789.630791] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
[ 1789.630796] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
[ 1789.630800] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
[ 1789.630806] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
[ 1789.630811] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
[ 1789.630816] [<ffffffff81591321>] rest_init+0xc1/0xd0
[ 1789.630822] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
[ 1789.630828] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
[ 1789.630833] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
[ 1789.630841]
stack backtrace:
[ 1789.630846] Pid: 0, comm: swapper/0 Not tainted 3.8.0+ #76
[ 1789.630849] Call Trace:
[ 1789.630851] <IRQ> [<ffffffff815a2065>] print_irq_inversion_bug.part.39+0x1b0/0x1bf
[ 1789.630865] [<ffffffff810ace86>] check_usage_forwards+0x136/0x140
[ 1789.630873] [<ffffffff810acd50>] ? check_usage_backwards+0x140/0x140
[ 1789.630880] [<ffffffff810ad6c6>] mark_lock+0x176/0x2b0
[ 1789.630886] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
[ 1789.630893] [<ffffffff810ad763>] ? mark_lock+0x213/0x2b0
[ 1789.630900] [<ffffffff810ae380>] ? __lock_acquire+0xb80/0x1cb0
[ 1789.630907] [<ffffffff810afab6>] lock_acquire+0x96/0x150
[ 1789.630913] [<ffffffff8151c6d8>] ? ip_expire+0x28/0x220
[ 1789.630919] [<ffffffff81009a69>] ? sched_clock+0x9/0x10
[ 1789.630925] [<ffffffff8151c6b0>] ? ip_check_defrag+0x1b0/0x1b0
[ 1789.630931] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
[ 1789.630938] [<ffffffff8151c6d8>] ? ip_expire+0x28/0x220
[ 1789.630943] [<ffffffff81009a69>] ? sched_clock+0x9/0x10
[ 1789.630949] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
[ 1789.630956] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
[ 1789.630961] [<ffffffff81056ad5>] ? call_timer_fn+0x5/0x1f0
[ 1789.630968] [<ffffffff8151c6b0>] ? ip_check_defrag+0x1b0/0x1b0
[ 1789.630974] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
[ 1789.630981] [<ffffffff814a11a0>] ? read_measured_perf_ctrs+0x90/0x90
[ 1789.630987] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
[ 1789.630994] [<ffffffff814a11a0>] ? read_measured_perf_ctrs+0x90/0x90
[ 1789.630999] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
[ 1789.631004] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
[ 1789.631010] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
[ 1789.631016] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
[ 1789.631022] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
[ 1789.631024] <EOI> [<ffffffff81034e1f>] ? leave_mm+0x6f/0xa0
[ 1789.631036] [<ffffffff814a1b98>] ? cpuidle_wrap_enter+0x58/0xa0
[ 1789.631042] [<ffffffff814a1b91>] ? cpuidle_wrap_enter+0x51/0xa0
[ 1789.631049] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
[ 1789.631055] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
[ 1789.631061] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
[ 1789.631067] [<ffffffff81591321>] rest_init+0xc1/0xd0
[ 1789.631074] [<ffffffff81591265>] ? rest_init+0x5/0xd0
[ 1789.631080] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
[ 1789.631086] [<ffffffff81cba8a1>] ? repair_env_string+0x5e/0x5e
[ 1789.631093] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
[ 1789.631098] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
^ permalink raw reply
* Re: lockdep trace from sockstat_seq_show
From: Eric Dumazet @ 2013-02-22 17:33 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, netdev
In-Reply-To: <20130222171343.GB27619@redhat.com>
On Fri, 2013-02-22 at 12:13 -0500, Dave Jones wrote:
> Just hit this on Linus' current tree.
>
> [ 1789.629729] =========================================================
> [ 1789.629731] [ INFO: possible irq lock inversion dependency detected ]
> [ 1789.629736] 3.8.0+ #76 Not tainted
> [ 1789.629738] ---------------------------------------------------------
> [ 1789.629742] swapper/0/0 just changed the state of lock:
> [ 1789.629744] blocked: (&(&q->lock)->rlock){+.-...}, instance: ffff88006c24da58, at: [<ffffffff8151c6d8>] ip_expire+0x28/0x220
> [ 1789.629762] but this lock took another, SOFTIRQ-unsafe lock in the past:
> [ 1789.629765] (key#15){+.+...}
>
> and interrupts could create inverse lock ordering between them.
>
> [ 1789.629772]
> other info that might help us debug this:
> [ 1789.629775] Possible interrupt unsafe locking scenario:
>
> [ 1789.629778] CPU0 CPU1
> [ 1789.629780] ---- ----
> [ 1789.629782] lock(key#15);
> [ 1789.629788] local_irq_disable();
> [ 1789.629790] lock(&(&q->lock)->rlock);
> [ 1789.629794] lock(key#15);
> [ 1789.629799] <Interrupt>
> [ 1789.629801] lock(&(&q->lock)->rlock);
> [ 1789.629805]
> *** DEADLOCK ***
>
> [ 1789.629809] 1 lock on stack by swapper/0/0:
> [ 1789.629812] #0: blocked: (((&q->timer))){+.-...}, instance: ffff880119803dd0, at: [<ffffffff81056ad5>] call_timer_fn+0x5/0x1f0
> [ 1789.629826]
> the shortest dependencies between 2nd lock and 1st lock:
> [ 1789.629844] -> (key#15){+.+...} ops: 132 {
> [ 1789.629854] HARDIRQ-ON-W at:
> [ 1789.629857] [<ffffffff810ade4a>] __lock_acquire+0x64a/0x1cb0
> [ 1789.629865] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.629871] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.629878] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
> [ 1789.629885] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
> [ 1789.629891] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
> [ 1789.629898] [<ffffffff811b744c>] seq_read+0xcc/0x460
> [ 1789.629904] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
> [ 1789.629910] [<ffffffff81193e5c>] vfs_read+0xac/0x180
> [ 1789.629916] [<ffffffff81193f85>] sys_read+0x55/0xa0
> [ 1789.629920] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
> [ 1789.629926] SOFTIRQ-ON-W at:
> [ 1789.629929] [<ffffffff810ade86>] __lock_acquire+0x686/0x1cb0
> [ 1789.629935] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.629941] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.629946] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
> [ 1789.629951] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
> [ 1789.629957] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
> [ 1789.629963] [<ffffffff811b744c>] seq_read+0xcc/0x460
> [ 1789.629968] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
> [ 1789.629973] [<ffffffff81193e5c>] vfs_read+0xac/0x180
> [ 1789.629977] [<ffffffff81193f85>] sys_read+0x55/0xa0
> [ 1789.629981] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
> [ 1789.629986] INITIAL USE at:
> [ 1789.629989] [<ffffffff810adb0d>] __lock_acquire+0x30d/0x1cb0
> [ 1789.629995] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630001] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630006] [<ffffffff81308d79>] __percpu_counter_sum+0x19/0xc0
> [ 1789.630012] [<ffffffff8151c905>] ip_frag_mem+0x15/0x30
> [ 1789.630017] [<ffffffff81567448>] sockstat_seq_show+0x128/0x170
> [ 1789.630023] [<ffffffff811b744c>] seq_read+0xcc/0x460
> [ 1789.630028] [<ffffffff811f5ec0>] proc_reg_read+0x80/0xc0
> [ 1789.630033] [<ffffffff81193e5c>] vfs_read+0xac/0x180
> [ 1789.630038] [<ffffffff81193f85>] sys_read+0x55/0xa0
> [ 1789.630042] [<ffffffff815b4a99>] system_call_fastpath+0x16/0x1b
> [ 1789.630047] }
> [ 1789.630049] ... key at: [<ffffffff829fb1e8>] __key.23045+0x0/0x8
> [ 1789.630055] ... acquired at:
> [ 1789.630057] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630063] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630068] [<ffffffff81308b74>] __percpu_counter_add+0x54/0xc0
> [ 1789.630073] [<ffffffff8151bea4>] ip_defrag+0x6e4/0xd40
> [ 1789.630079] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
> [ 1789.630084] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
> [ 1789.630090] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
> [ 1789.630095] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
> [ 1789.630099] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
> [ 1789.630103] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
> [ 1789.630132] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
> [ 1789.630152] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
> [ 1789.630170] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
> [ 1789.630188] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
> [ 1789.630201] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
> [ 1789.630212] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
> [ 1789.630225] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
> [ 1789.630232] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
> [ 1789.630237] [<ffffffff8106c5ed>] kthread+0xed/0x100
> [ 1789.630243] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
>
> [ 1789.630251] -> (&(&q->lock)->rlock){+.-...} ops: 18 {
> [ 1789.630260] HARDIRQ-ON-W at:
> [ 1789.630264] [<ffffffff810ade4a>] __lock_acquire+0x64a/0x1cb0
> [ 1789.630270] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630276] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630281] [<ffffffff8151b8df>] ip_defrag+0x11f/0xd40
> [ 1789.630287] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
> [ 1789.630292] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
> [ 1789.630297] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
> [ 1789.630301] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
> [ 1789.630305] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
> [ 1789.630310] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
> [ 1789.630330] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
> [ 1789.630348] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
> [ 1789.630365] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
> [ 1789.630382] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
> [ 1789.630392] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
> [ 1789.630402] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
> [ 1789.630412] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
> [ 1789.630418] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
> [ 1789.630423] [<ffffffff8106c5ed>] kthread+0xed/0x100
> [ 1789.630429] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
> [ 1789.630434] IN-SOFTIRQ-W at:
> [ 1789.630437] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
> [ 1789.630444] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630449] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630454] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
> [ 1789.630460] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
> [ 1789.630466] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
> [ 1789.630471] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
> [ 1789.630478] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
> [ 1789.630483] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
> [ 1789.630488] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
> [ 1789.630494] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
> [ 1789.630499] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
> [ 1789.630504] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
> [ 1789.630510] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
> [ 1789.630516] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
> [ 1789.630521] [<ffffffff81591321>] rest_init+0xc1/0xd0
> [ 1789.630528] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
> [ 1789.630536] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
> [ 1789.630541] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
> [ 1789.630547] INITIAL USE at:
> [ 1789.630550] [<ffffffff810adb0d>] __lock_acquire+0x30d/0x1cb0
> [ 1789.630556] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630562] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630566] [<ffffffff8151b8df>] ip_defrag+0x11f/0xd40
> [ 1789.630572] [<ffffffff8151ac64>] ip_local_deliver+0x34/0x2e0
> [ 1789.630577] [<ffffffff8151b27d>] ip_rcv+0x36d/0x5c0
> [ 1789.630583] [<ffffffff814eec6a>] __netif_receive_skb_core+0x3da/0x6d0
> [ 1789.630587] [<ffffffff814eef81>] __netif_receive_skb+0x21/0x70
> [ 1789.630591] [<ffffffff814ef193>] netif_receive_skb+0x23/0x100
> [ 1789.630595] [<ffffffffa04cacf3>] ieee80211_deliver_skb.isra.30+0xa3/0x200 [mac80211]
> [ 1789.630615] [<ffffffffa04cc16e>] ieee80211_rx_handlers+0xcae/0x23b0 [mac80211]
> [ 1789.630631] [<ffffffffa04cda10>] ieee80211_prepare_and_rx_handle+0x1a0/0xb00 [mac80211]
> [ 1789.630647] [<ffffffffa04ce69d>] ieee80211_rx+0x32d/0x910 [mac80211]
> [ 1789.630664] [<ffffffffa0584280>] iwlagn_rx_reply_rx+0x3f0/0x760 [iwldvm]
> [ 1789.630674] [<ffffffffa0585473>] iwl_rx_dispatch+0xa3/0x110 [iwldvm]
> [ 1789.630684] [<ffffffffa02d95cf>] iwl_pcie_irq_handler+0x93f/0xe00 [iwlwifi]
> [ 1789.630694] [<ffffffff810db569>] irq_thread_fn+0x29/0x50
> [ 1789.630700] [<ffffffff810dbacf>] irq_thread+0x12f/0x160
> [ 1789.630705] [<ffffffff8106c5ed>] kthread+0xed/0x100
> [ 1789.630711] [<ffffffff815b49ec>] ret_from_fork+0x7c/0xb0
> [ 1789.630716] }
> [ 1789.630718] ... key at: [<ffffffff829fb1f8>] __key.32665+0x0/0x8
> [ 1789.630723] ... acquired at:
> [ 1789.630726] [<ffffffff810ace86>] check_usage_forwards+0x136/0x140
> [ 1789.630732] [<ffffffff810ad6c6>] mark_lock+0x176/0x2b0
> [ 1789.630737] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
> [ 1789.630743] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630748] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630753] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
> [ 1789.630759] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
> [ 1789.630765] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
> [ 1789.630770] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
> [ 1789.630776] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
> [ 1789.630781] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
> [ 1789.630785] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
> [ 1789.630791] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
> [ 1789.630796] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
> [ 1789.630800] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
> [ 1789.630806] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
> [ 1789.630811] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
> [ 1789.630816] [<ffffffff81591321>] rest_init+0xc1/0xd0
> [ 1789.630822] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
> [ 1789.630828] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
> [ 1789.630833] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
>
> [ 1789.630841]
> stack backtrace:
> [ 1789.630846] Pid: 0, comm: swapper/0 Not tainted 3.8.0+ #76
> [ 1789.630849] Call Trace:
> [ 1789.630851] <IRQ> [<ffffffff815a2065>] print_irq_inversion_bug.part.39+0x1b0/0x1bf
> [ 1789.630865] [<ffffffff810ace86>] check_usage_forwards+0x136/0x140
> [ 1789.630873] [<ffffffff810acd50>] ? check_usage_backwards+0x140/0x140
> [ 1789.630880] [<ffffffff810ad6c6>] mark_lock+0x176/0x2b0
> [ 1789.630886] [<ffffffff810ade03>] __lock_acquire+0x603/0x1cb0
> [ 1789.630893] [<ffffffff810ad763>] ? mark_lock+0x213/0x2b0
> [ 1789.630900] [<ffffffff810ae380>] ? __lock_acquire+0xb80/0x1cb0
> [ 1789.630907] [<ffffffff810afab6>] lock_acquire+0x96/0x150
> [ 1789.630913] [<ffffffff8151c6d8>] ? ip_expire+0x28/0x220
> [ 1789.630919] [<ffffffff81009a69>] ? sched_clock+0x9/0x10
> [ 1789.630925] [<ffffffff8151c6b0>] ? ip_check_defrag+0x1b0/0x1b0
> [ 1789.630931] [<ffffffff815ac090>] _raw_spin_lock+0x40/0x80
> [ 1789.630938] [<ffffffff8151c6d8>] ? ip_expire+0x28/0x220
> [ 1789.630943] [<ffffffff81009a69>] ? sched_clock+0x9/0x10
> [ 1789.630949] [<ffffffff8151c6d8>] ip_expire+0x28/0x220
> [ 1789.630956] [<ffffffff81056b5a>] call_timer_fn+0x8a/0x1f0
> [ 1789.630961] [<ffffffff81056ad5>] ? call_timer_fn+0x5/0x1f0
> [ 1789.630968] [<ffffffff8151c6b0>] ? ip_check_defrag+0x1b0/0x1b0
> [ 1789.630974] [<ffffffff81056ef4>] run_timer_softirq+0x234/0x2e0
> [ 1789.630981] [<ffffffff814a11a0>] ? read_measured_perf_ctrs+0x90/0x90
> [ 1789.630987] [<ffffffff8104eae8>] __do_softirq+0xf8/0x2b0
> [ 1789.630994] [<ffffffff814a11a0>] ? read_measured_perf_ctrs+0x90/0x90
> [ 1789.630999] [<ffffffff815b5e3c>] call_softirq+0x1c/0x26
> [ 1789.631004] [<ffffffff81003eb5>] do_softirq+0xa5/0xe0
> [ 1789.631010] [<ffffffff8104ee85>] irq_exit+0xd5/0xe0
> [ 1789.631016] [<ffffffff815b5f8b>] smp_apic_timer_interrupt+0x6b/0x98
> [ 1789.631022] [<ffffffff815b56f2>] apic_timer_interrupt+0x72/0x80
> [ 1789.631024] <EOI> [<ffffffff81034e1f>] ? leave_mm+0x6f/0xa0
> [ 1789.631036] [<ffffffff814a1b98>] ? cpuidle_wrap_enter+0x58/0xa0
> [ 1789.631042] [<ffffffff814a1b91>] ? cpuidle_wrap_enter+0x51/0xa0
> [ 1789.631049] [<ffffffff814a1bf0>] cpuidle_enter_tk+0x10/0x20
> [ 1789.631055] [<ffffffff814a1835>] cpuidle_idle_call+0xa5/0x250
> [ 1789.631061] [<ffffffff8100b545>] cpu_idle+0xd5/0x170
> [ 1789.631067] [<ffffffff81591321>] rest_init+0xc1/0xd0
> [ 1789.631074] [<ffffffff81591265>] ? rest_init+0x5/0xd0
> [ 1789.631080] [<ffffffff81cbaea5>] start_kernel+0x403/0x410
> [ 1789.631086] [<ffffffff81cba8a1>] ? repair_env_string+0x5e/0x5e
> [ 1789.631093] [<ffffffff81cba59b>] x86_64_start_reservations+0x2a/0x2c
> [ 1789.631098] [<ffffffff81cba689>] x86_64_start_kernel+0xec/0xfb
>
Hmm, thanks for the report. I am testing a fix.
^ permalink raw reply
* [PATCH] net: fix possible deadlock in sum_frag_mem_limit
From: Eric Dumazet @ 2013-02-22 17:43 UTC (permalink / raw)
To: Dave Jones, David Miller; +Cc: Linux Kernel, netdev, Jesper Dangaard Brouer
In-Reply-To: <20130222171343.GB27619@redhat.com>
From: Eric Dumazet <edumazet@google.com>
Dave Jones reported a lockdep splat occurring in IP defrag code.
commit 6d7b857d541ecd1d (net: use lib/percpu_counter API for
fragmentation mem accounting) added a possible deadlock.
Because percpu_counter_sum_positive() needs to acquire
a lock that can be used from softirq, we need to disable BH
in sum_frag_mem_limit()
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/net/inet_frag.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index 3f237db..76c3fe5 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -114,7 +114,13 @@ static inline void init_frag_mem_limit(struct netns_frags *nf)
static inline int sum_frag_mem_limit(struct netns_frags *nf)
{
- return percpu_counter_sum_positive(&nf->mem);
+ int res;
+
+ local_bh_disable();
+ res = percpu_counter_sum_positive(&nf->mem);
+ local_bh_enable();
+
+ return res;
}
static inline void inet_frag_lru_move(struct inet_frag_queue *q)
^ permalink raw reply related
* Re: xen-netback fixes for stable 35876b5 3e55f8b
From: Ian Campbell @ 2013-02-22 17:44 UTC (permalink / raw)
To: William Dauchy
Cc: stable@vger.kernel.org, Greg Kroah-Hartman, Ben Hutchings,
linux-kernel@vger.kernel.org, David Vrabel, Christopher S. Aker,
David Miller, netdev
In-Reply-To: <20130222164728.GB27794@gandi.net>
Adding Dave Miller, the networking maintainer. He needs to ack such
requests I think. Adding netdev too for good meassure.
On Fri, 2013-02-22 at 16:47 +0000, William Dauchy wrote:
> Hello,
>
> I believe the two commits 35876b5 and 3e55f8b could be included in stable tree.
> 35876b5 is related to 4885628 already in the stable tree and fixes a
> possible oops.
> 3e55f8b is fixing another possible oops (see commit messages).
DaveM has these queued for stable already:
http://marc.info/?l=xen-devel&m=136086628711282&w=2
He likes to soak thing in mainline for a bit before forwarding to stable
which is likely why they aren't there yet
http://marc.info/?l=xen-devel&m=136029801624783&w=2
Ian.
^ permalink raw reply
* Re: xen-netback fixes for stable 35876b5 3e55f8b
From: William Dauchy @ 2013-02-22 17:51 UTC (permalink / raw)
To: Ian Campbell
Cc: William Dauchy, stable@vger.kernel.org, Greg Kroah-Hartman,
Ben Hutchings, linux-kernel@vger.kernel.org, David Vrabel,
Christopher S. Aker, David Miller, netdev
In-Reply-To: <1361555068.26546.144.camel@zakaz.uk.xensource.com>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Feb22 17:44, Ian Campbell wrote:
> He likes to soak thing in mainline for a bit before forwarding to stable
> which is likely why they aren't there yet
> http://marc.info/?l=xen-devel&m=136029801624783&w=2
ack, didn't know that.
--
William
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Fw: [Bug 54231] r8169 driver regression caused by the commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
From: Stephen Hemminger @ 2013-02-22 17:55 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
Begin forwarded message:
Date: Fri, 22 Feb 2013 08:41:04 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 54231] r8169 driver regression caused by the commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
https://bugzilla.kernel.org/show_bug.cgi?id=54231
--- Comment #1 from Tomi Orava <tomimo@ncircle.nullnet.fi> 2013-02-22 16:40:49 ---
Although the r8169 has been working just fine on 3.4.31 for the past 5 days, it
seems that I missed the second DMA Burst setting in the previous patch that
should get fixed as well:
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -77,6 +77,7 @@
static const int multicast_filter_limit = 32;
#define MAX_READ_REQUEST_SHIFT 12
+#define TX_DMA_BURST_512 5 /* Maximum PCI burst, limited to 512
*/
#define TX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */
#define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one
*/
@@ -4406,8 +4407,14 @@ static void rtl_set_rx_tx_config_registers(struct
rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
/* Set DMA burst size and Interframe Gap Time */
- RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) |
- (InterFrameGap << TxInterFrameGapShift));
+
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
+ RTL_W32(TxConfig, (TX_DMA_BURST_512 << TxDMAShift) |
+ (InterFrameGap << TxInterFrameGapShift));
+ } else {
+ RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) |
+ (InterFrameGap << TxInterFrameGapShift));
+ }
}
static void rtl_hw_start(struct net_device *dev)
@@ -5148,8 +5155,13 @@ static void rtl_hw_start_8168(struct net_device *dev)
rtl_set_rx_mode(dev);
- RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) |
- (InterFrameGap << TxInterFrameGapShift));
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
+ RTL_W32(TxConfig, (TX_DMA_BURST_512 << TxDMAShift) |
+ (InterFrameGap << TxInterFrameGapShift));
+ } else {
+ RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) |
+ (InterFrameGap << TxInterFrameGapShift));
+ }
RTL_R8(IntrMask);
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH net] sock: only define socket limit if mem cgroup configured
From: Stephen Hemminger @ 2013-02-22 17:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The mem cgroup socket limit is only used if the config option is
enabled. Found with sparse
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/core/sock.c 2013-02-21 13:52:10.000000000 -0800
+++ b/net/core/sock.c 2013-02-21 21:03:06.075605811 -0800
@@ -186,8 +186,10 @@ void mem_cgroup_sockets_destroy(struct m
static struct lock_class_key af_family_keys[AF_MAX];
static struct lock_class_key af_family_slock_keys[AF_MAX];
+#if defined(CONFIG_MEMCG_KMEM)
struct static_key memcg_socket_limit_enabled;
EXPORT_SYMBOL(memcg_socket_limit_enabled);
+#endif
/*
* Make lock validator output more readable. (we pre-construct these
^ permalink raw reply
* [PATCH net] bnx2x: remove dead code and make local funcs static
From: Stephen Hemminger @ 2013-02-22 18:01 UTC (permalink / raw)
To: Eilon Greenstein, David Miller; +Cc: netdev
Sparse warned about several functions that were unnecessarily global.
After making them static, discovered that several functions were actually never used.
Compile tested only.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c 2013-01-24 08:39:16.000000000 -0800
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c 2013-02-21 21:30:43.266173259 -0800
@@ -98,7 +98,7 @@ static inline int bnx2x_pfvf_status_code
}
}
-int bnx2x_send_msg2pf(struct bnx2x *bp, u8 *done, dma_addr_t msg_mapping)
+static int bnx2x_send_msg2pf(struct bnx2x *bp, u8 *done, dma_addr_t msg_mapping)
{
struct cstorm_vf_zone_data __iomem *zone_data =
REG_ADDR(bp, PXP_VF_ADDR_CSDM_GLOBAL_START);
@@ -141,7 +141,7 @@ int bnx2x_send_msg2pf(struct bnx2x *bp,
return 0;
}
-int bnx2x_get_vf_id(struct bnx2x *bp, u32 *vf_id)
+static int bnx2x_get_vf_id(struct bnx2x *bp, u32 *vf_id)
{
u32 me_reg;
int tout = 10, interval = 100; /* Wait for 1 sec */
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c 2013-02-05 09:22:48.000000000 -0800
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c 2013-02-21 21:36:46.057481259 -0800
@@ -13013,64 +13013,6 @@ static int bnx2x_84833_common_init_phy(s
return 0;
}
-static int bnx2x_84833_pre_init_phy(struct bnx2x *bp,
- struct bnx2x_phy *phy,
- u8 port)
-{
- u16 val, cnt;
- /* Wait for FW completing its initialization. */
- for (cnt = 0; cnt < 1500; cnt++) {
- bnx2x_cl45_read(bp, phy,
- MDIO_PMA_DEVAD,
- MDIO_PMA_REG_CTRL, &val);
- if (!(val & (1<<15)))
- break;
- usleep_range(1000, 2000);
- }
- if (cnt >= 1500) {
- DP(NETIF_MSG_LINK, "84833 reset timeout\n");
- return -EINVAL;
- }
-
- /* Put the port in super isolate mode. */
- bnx2x_cl45_read(bp, phy,
- MDIO_CTL_DEVAD,
- MDIO_84833_TOP_CFG_XGPHY_STRAP1, &val);
- val |= MDIO_84833_SUPER_ISOLATE;
- bnx2x_cl45_write(bp, phy,
- MDIO_CTL_DEVAD,
- MDIO_84833_TOP_CFG_XGPHY_STRAP1, val);
-
- /* Save spirom version */
- bnx2x_save_848xx_spirom_version(phy, bp, port);
- return 0;
-}
-
-int bnx2x_pre_init_phy(struct bnx2x *bp,
- u32 shmem_base,
- u32 shmem2_base,
- u32 chip_id,
- u8 port)
-{
- int rc = 0;
- struct bnx2x_phy phy;
- if (bnx2x_populate_phy(bp, EXT_PHY1, shmem_base, shmem2_base,
- port, &phy) != 0) {
- DP(NETIF_MSG_LINK, "populate_phy failed\n");
- return -EINVAL;
- }
- bnx2x_set_mdio_clk(bp, chip_id, phy.mdio_ctrl);
- switch (phy.type) {
- case PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM84833:
- case PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM84834:
- rc = bnx2x_84833_pre_init_phy(bp, &phy, port);
- break;
- default:
- break;
- }
- return rc;
-}
-
static int bnx2x_ext_phy_common_init(struct bnx2x *bp, u32 shmem_base_path[],
u32 shmem2_base_path[], u8 phy_index,
u32 ext_phy_type, u32 chip_id)
^ permalink raw reply
* [PATCH net] vmxnet3: make local function static
From: Stephen Hemminger @ 2013-02-22 18:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/vmxnet3/vmxnet3_drv.c 2013-02-21 21:35:42.998296803 -0800
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c 2013-02-21 21:41:45.149613077 -0800
@@ -1385,8 +1385,8 @@ vmxnet3_rq_cleanup_all(struct vmxnet3_ad
}
-void vmxnet3_rq_destroy(struct vmxnet3_rx_queue *rq,
- struct vmxnet3_adapter *adapter)
+static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue *rq,
+ struct vmxnet3_adapter *adapter)
{
int i;
int j;
^ permalink raw reply
* Re: batman-adv: gpf in batadv_slide_own_bcast_window
From: Sasha Levin @ 2013-02-22 18:37 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev, linux-kernel@vger.kernel.org, Dave Jones
In-Reply-To: <20130222170621.GU3523@ritirata.org>
On 02/22/2013 12:06 PM, Antonio Quartulli wrote:
> Hi Sasha and thank you very much for reporting this issue.
>
> IIRC this is similar to a bug you already reported in the past.
> This bug should be the result of a race condition batman-adv has in the
> hard-interface handling code (this is why it has been triggered while removing
> eth0).
>
> Now that the rtnl-deadlock has been solved I think we can try to further
> investigate on this bug and try to find a solution..though it will not be easy
> as it probably requires another lock to protect the hard-interface during this
> operations.
>
> If you have any fix proposal feel free to contribute!
I'm confused about how batadv_orig_hash_del_if removes an interface from the
hashtable. I see the hashtable is using rcu to protect it, but when we
delete an entry we free it straight away by calling batadv_orig_node_del_if()
and not going through kfree_rcu().
Is there a reason behind doing that, or might it be the cause of the problem
we're seeing here?
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] tcp: fix SYN-data space mis-accounting
From: Neal Cardwell @ 2013-02-22 19:23 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Netdev
In-Reply-To: <1361559546-1538-1-git-send-email-ycheng@google.com>
On Fri, Feb 22, 2013 at 1:59 PM, Yuchung Cheng <ycheng@google.com> wrote:
> In fast open the sender unncessarily reduces the space available
> for data in SYN by 12 bytes. This is because in the sender
> incorrectly reserves space for TS option twice in tcp_send_syn_data():
> tcp_mtu_to_mss() already accounts for TS option space. But it further
> reserves MAX_TCP_OPTION_SPACE when computing the payload space.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
^ permalink raw reply
* [PATCH] tcp: fix SYN-data space mis-accounting
From: Yuchung Cheng @ 2013-02-22 18:59 UTC (permalink / raw)
To: davem, ncardwell, edumazet; +Cc: netdev, Yuchung Cheng
In fast open the sender unncessarily reduces the space available
for data in SYN by 12 bytes. This is because in the sender
incorrectly reserves space for TS option twice in tcp_send_syn_data():
tcp_mtu_to_mss() already accounts for TS option space. But it further
reserves MAX_TCP_OPTION_SPACE when computing the payload space.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_output.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index fd0cea1..e2b4461 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1351,8 +1351,8 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
return 0;
}
-/* Calculate MSS. Not accounting for SACKs here. */
-int tcp_mtu_to_mss(struct sock *sk, int pmtu)
+/* Calculate MSS not accounting any TCP options. */
+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1381,13 +1381,17 @@ int tcp_mtu_to_mss(struct sock *sk, int pmtu)
/* Then reserve room for full set of TCP options and 8 bytes of data */
if (mss_now < 48)
mss_now = 48;
-
- /* Now subtract TCP options size, not including SACKs */
- mss_now -= tp->tcp_header_len - sizeof(struct tcphdr);
-
return mss_now;
}
+/* Calculate MSS. Not accounting for SACKs here. */
+int tcp_mtu_to_mss(struct sock *sk, int pmtu)
+{
+ /* Subtract TCP options size, not including SACKs */
+ return __tcp_mtu_to_mss(sk, pmtu) -
+ (tcp_sk(sk)->tcp_header_len - sizeof(struct tcphdr));
+}
+
/* Inverse of above */
int tcp_mss_to_mtu(struct sock *sk, int mss)
{
@@ -2930,7 +2934,7 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
*/
if (tp->rx_opt.user_mss && tp->rx_opt.user_mss < tp->rx_opt.mss_clamp)
tp->rx_opt.mss_clamp = tp->rx_opt.user_mss;
- space = tcp_mtu_to_mss(sk, inet_csk(sk)->icsk_pmtu_cookie) -
+ space = __tcp_mtu_to_mss(sk, inet_csk(sk)->icsk_pmtu_cookie) -
MAX_TCP_OPTION_SPACE;
syn_data = skb_copy_expand(syn, skb_headroom(syn), space,
--
1.8.1.3
^ permalink raw reply related
* Re: [PATCH] tcp: fix SYN-data space mis-accounting
From: Eric Dumazet @ 2013-02-22 19:40 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: davem, ncardwell, edumazet, netdev
In-Reply-To: <1361559546-1538-1-git-send-email-ycheng@google.com>
On Fri, 2013-02-22 at 10:59 -0800, Yuchung Cheng wrote:
> In fast open the sender unncessarily reduces the space available
> for data in SYN by 12 bytes. This is because in the sender
> incorrectly reserves space for TS option twice in tcp_send_syn_data():
> tcp_mtu_to_mss() already accounts for TS option space. But it further
> reserves MAX_TCP_OPTION_SPACE when computing the payload space.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] tcp: fix SYN-data space mis-accounting
From: David Miller @ 2013-02-22 20:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: ycheng, ncardwell, edumazet, netdev
In-Reply-To: <1361562058.3683.15.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 22 Feb 2013 11:40:58 -0800
> On Fri, 2013-02-22 at 10:59 -0800, Yuchung Cheng wrote:
>> In fast open the sender unncessarily reduces the space available
>> for data in SYN by 12 bytes. This is because in the sender
>> incorrectly reserves space for TS option twice in tcp_send_syn_data():
>> tcp_mtu_to_mss() already accounts for TS option space. But it further
>> reserves MAX_TCP_OPTION_SPACE when computing the payload space.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, and queue up for -stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH net] sock: only define socket limit if mem cgroup configured
From: David Miller @ 2013-02-22 20:14 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20130222095910.3ce8074b@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 22 Feb 2013 09:59:10 -0800
> The mem cgroup socket limit is only used if the config option is
> enabled. Found with sparse
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix possible deadlock in sum_frag_mem_limit
From: David Miller @ 2013-02-22 20:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, linux-kernel, netdev, brouer
In-Reply-To: <1361555015.3683.14.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 22 Feb 2013 09:43:35 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Dave Jones reported a lockdep splat occurring in IP defrag code.
>
> commit 6d7b857d541ecd1d (net: use lib/percpu_counter API for
> fragmentation mem accounting) added a possible deadlock.
>
> Because percpu_counter_sum_positive() needs to acquire
> a lock that can be used from softirq, we need to disable BH
> in sum_frag_mem_limit()
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fec: Fix division by zero
From: David Miller @ 2013-02-22 20:14 UTC (permalink / raw)
To: fabio.estevam; +Cc: Frank.Li, s.hauer, jim_baxter, netdev
In-Reply-To: <1361551245-11021-1-git-send-email-fabio.estevam@freescale.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
Date: Fri, 22 Feb 2013 13:40:45 -0300
> commit 7f7d6c282 (net: fec: Ensure that initialization is done prior to
> request_irq()) placed fec_ptp_init() into a point that ptp clock was not
> available, which causes a division by zero in fec_ptp_start_cyclecounter():
>
> [ 17.895723] Division by zero in kernel.
> [ 17.899571] Backtrace:
> [ 17.902094] [<80012564>] (dump_backtrace+0x0/0x10c) from [<8056deec>]
> (dump_stack+0x18/0x1c)
> [ 17.910539] r6:bfba8500 r5:8075c950 r4:bfba8000 r3:bfbd0000
> [ 17.916284] [<8056ded4>] (dump_stack+0x0/0x1c) from [<80012688>]
> (__div0+0x18/0x20)
> [ 17.923968] [<80012670>] (__div0+0x0/0x20) from [<802829c4>] (Ldiv0+0x8/0x10)
> [ 17.931140] [<80398534>] (fec_ptp_start_cyclecounter+0x0/0x110) from
> [<80394f64>] (fec_restart+0x6c8/0x754)
> [ 17.940898] [<8039489c>] (fec_restart+0x0/0x754) from [<803969a0>]
> (fec_enet_adjust_link+0xdc/0x108)
> [ 17.950046] [<803968c4>] (fec_enet_adjust_link+0x0/0x108) from [<80390bc4>]
> (phy_state_machine+0x178/0x534)
> ...
>
> Fix this by rearraging the code so that fec_ptp_init() is called only after
> the clocks have been properly acquired.
>
> Tested on both mx53 and mx6 platforms.
>
> Reported-by: Jim Baxter <jim_baxter@mentor.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Fix locking bug in netif_set_xps_queue
From: David Miller @ 2013-02-22 20:14 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, fengguang.wu, dan.carpenter, jeffrey.t.kirsher
In-Reply-To: <20130222163806.7590.98066.stgit@ahduyck-cp1.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 22 Feb 2013 08:38:44 -0800
> Smatch found a locking bug in netif_set_xps_queue in which we were not
> releasing the lock in the case of an allocation failure.
>
> This change corrects that so that we release the xps_map_mutex before
> returning -ENOMEM in the case of an allocation failure.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied and queue up for -stable, thanks Alex.
^ permalink raw reply
* Re: [PATCH] ipv4: fix error handling in icmp_protocol.
From: David Miller @ 2013-02-22 20:15 UTC (permalink / raw)
To: lw; +Cc: netdev
In-Reply-To: <1361521124-1135-1-git-send-email-lw@cn.fujitsu.com>
From: Li Wei <lw@cn.fujitsu.com>
Date: Fri, 22 Feb 2013 16:18:44 +0800
> Now we handle icmp errors in each transport protocol's err_handler,
> for icmp protocols, that is ping_err. Since this handler only care
> of those icmp errors triggered by echo request, errors triggered
> by echo reply(which sent by kernel) are sliently ignored.
>
> So wrap ping_err() with icmp_err() to deal with those icmp errors.
>
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
Applied and queue up for -stable, thanks.
^ permalink raw reply
* [PATCH net-next] vmxnet3: fix ethtool ring buffer size setting
From: Neil Horman @ 2013-02-22 20:32 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Shreyas Bhatewara, VMware, Inc., David S. Miller
Noticed that vmxnet3's get_ringparam function was returning the summation of all
ring buffers on a NIC, rather than just the size of any one ring. This causes
problems when a vmxnet3 instance has multiple queues, as ethtool, when setting
ring parameters, first gets the current ring parameters to set the existing
values in the set_ringparm commannd. The result is, that unless both rx and tx
ring sizes are set in a single operation, which ever ring is not set will
silently have its ring count multiplied by the number of queues on the NIC until
it reaches a driver defined maxiumum value.
Fix it by not multiplying the rx and tx ring sizes by the number of queues in
the system, like every other driver. Tested by myself successfully.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Shreyas Bhatewara <sbhatewara@vmware.com>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/vmxnet3/vmxnet3_ethtool.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index 9bc542b..a0feb17 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -448,10 +448,8 @@ vmxnet3_get_ringparam(struct net_device *netdev,
param->rx_mini_max_pending = 0;
param->rx_jumbo_max_pending = 0;
- param->rx_pending = adapter->rx_queue[0].rx_ring[0].size *
- adapter->num_rx_queues;
- param->tx_pending = adapter->tx_queue[0].tx_ring.size *
- adapter->num_tx_queues;
+ param->rx_pending = adapter->rx_queue[0].rx_ring[0].size;
+ param->tx_pending = adapter->tx_queue[0].tx_ring.size;
param->rx_mini_pending = 0;
param->rx_jumbo_pending = 0;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 1/1] net: fec: fix miss init spinlock
From: Fabio Estevam @ 2013-02-22 21:17 UTC (permalink / raw)
To: Jim Baxter; +Cc: netdev, Li Frank-B20596
In-Reply-To: <loom.20130222T132206-265@post.gmane.org>
Hi Jim,
On Fri, Feb 22, 2013 at 9:25 AM, Jim Baxter <jim_baxter@mentor.com> wrote:
> Hi Frank,
>
> Have you had time to have a look at this issues again?
Can you try again using the latest net tree from David Miller?
^ permalink raw reply
* Re: [PATCH] net: Fix locking bug in netif_set_xps_queue
From: Alexander Duyck @ 2013-02-22 21:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fengguang.wu, dan.carpenter, jeffrey.t.kirsher
In-Reply-To: <20130222.151442.333174353561165623.davem@davemloft.net>
On 02/22/2013 12:14 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Fri, 22 Feb 2013 08:38:44 -0800
>
>> Smatch found a locking bug in netif_set_xps_queue in which we were not
>> releasing the lock in the case of an allocation failure.
>>
>> This change corrects that so that we release the xps_map_mutex before
>> returning -ENOMEM in the case of an allocation failure.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Applied and queue up for -stable, thanks Alex.
No patch is needed for -stable. This was something I had introduced
into net-next when I moved the XPS logic into its own function.
Thanks,
Alex
^ permalink raw reply
* LOAN CONTACT
From: Mr. Nelson Emmanuel @ 2013-02-22 21:30 UTC (permalink / raw)
To: Recipients
My name is MR. NELSON EMMANUEL ,I am a private lender who give out
loan to private and corporate individuals. Have you been turned down
by so many banks? Do you need finance to establish your business? Do
you need finance for the expansion of your business? Or do you need a
personal loan of 5%
All Reply should be sent to this Email : mrnelsonemmanuel@zing.vn
^ permalink raw reply
* Re: [PATCH] net: Fix locking bug in netif_set_xps_queue
From: David Miller @ 2013-02-22 21:44 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, fengguang.wu, dan.carpenter, jeffrey.t.kirsher
In-Reply-To: <5127E145.2070008@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 22 Feb 2013 13:21:09 -0800
> On 02/22/2013 12:14 PM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> Date: Fri, 22 Feb 2013 08:38:44 -0800
>>
>>> Smatch found a locking bug in netif_set_xps_queue in which we were not
>>> releasing the lock in the case of an allocation failure.
>>>
>>> This change corrects that so that we release the xps_map_mutex before
>>> returning -ENOMEM in the case of an allocation failure.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Applied and queue up for -stable, thanks Alex.
>
> No patch is needed for -stable. This was something I had introduced
> into net-next when I moved the XPS logic into its own function.
Great, thanks for letting me know.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox