* possible unannotated irqs-off
@ 2017-02-14 19:28 Ricardo Nabinger Sanchez
2017-02-14 19:46 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Nabinger Sanchez @ 2017-02-14 19:28 UTC (permalink / raw)
To: Realtek linux nic maintainers; +Cc: netdev
Greetings,
This has been popping out in my machine since 4.9 (now using 4.10-rc5),
even before having VMware's modules loaded.
Please advise whether this is actually from RTL8169 or whether I should
post somewhere else (feel free to redirect, though). Let me know if you
need more info and/or testing things.
Cheers,
====
[ 93.509046] ------------[ cut here ]------------
[ 93.509070] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3687 check_flags.part.45+0x1d8/0x1e0
[ 93.509076] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
[ 93.509078] Modules linked in: vmnet(O) vmmon(O)
[ 93.509095] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.10.0-rc5 #1
[ 93.509100] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ 93.509105] Call Trace:
[ 93.509111] <IRQ>
[ 93.509121] dump_stack+0x99/0xd9
[ 93.509130] __warn+0xcb/0xf0
[ 93.509137] warn_slowpath_fmt+0x4f/0x60
[ 93.509144] check_flags.part.45+0x1d8/0x1e0
[ 93.509150] lock_acquire+0x1c1/0x270
[ 93.509158] _raw_spin_lock+0x41/0x80
[ 93.509167] ? jtcp_rcv_established+0x8e/0x2d0
[ 93.509173] jtcp_rcv_established+0x8e/0x2d0
[ 93.509182] tcp_v4_do_rcv+0x142/0x200
[ 93.509189] tcp_v4_rcv+0xae9/0xb80
[ 93.509198] ip_local_deliver_finish+0xba/0x390
[ 93.509205] ? ip_local_deliver_finish+0x26/0x390
[ 93.509212] ip_local_deliver+0x1b9/0x200
[ 93.509218] ? ip_local_deliver+0x58/0x200
[ 93.509224] ? ip_rcv_finish+0x680/0x680
[ 93.509231] ip_rcv_finish+0x1a0/0x680
[ 93.509238] ip_rcv+0x367/0x500
[ 93.509243] ? ip_rcv+0x277/0x500
[ 93.509250] ? inet_del_offload+0x40/0x40
[ 93.509258] __netif_receive_skb_core+0x5d3/0xd00
[ 93.509265] ? netif_receive_skb_internal+0x50/0x1d0
[ 93.509271] __netif_receive_skb+0x1d/0x60
[ 93.509277] netif_receive_skb_internal+0x9c/0x1d0
[ 93.509283] ? netif_receive_skb_internal+0x50/0x1d0
[ 93.509289] napi_gro_receive+0x155/0x220
[ 93.509297] rtl8169_poll+0x2c5/0x670
[ 93.509304] net_rx_action+0x1f0/0x440
[ 93.509314] __do_softirq+0x1d4/0x512
[ 93.509322] irq_exit+0xcb/0xd0
[ 93.509329] do_IRQ+0x71/0x130
[ 93.509335] common_interrupt+0x93/0x93
[ 93.509347] RIP: 0010:cpuidle_enter_state+0xcf/0x400
[ 93.509351] RSP: 0018:ffffffffb6403df0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffffbd
[ 93.509358] RAX: ffffffffb6428500 RBX: 0000000000000002 RCX: 000000000000001f
[ 93.509363] RDX: 0000000000000001 RSI: ffffffffb62346a2 RDI: ffffffffb61ac1df
[ 93.509367] RBP: ffffffffb6403e28 R08: 000000000000001f R09: 0000000000000000
[ 93.509371] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
[ 93.509375] R13: ffff9e46cdfe1ec8 R14: ffffffffb64f9338 R15: 00000015c4ad440d
[ 93.509380] </IRQ>
[ 93.509391] cpuidle_enter+0x17/0x20
[ 93.509398] call_cpuidle+0x23/0x50
[ 93.509405] do_idle+0x185/0x220
[ 93.509413] cpu_startup_entry+0x62/0x70
[ 93.509420] rest_init+0x131/0x140
[ 93.509429] start_kernel+0x466/0x473
[ 93.509437] ? early_idt_handler_array+0x120/0x120
[ 93.509445] x86_64_start_reservations+0x24/0x26
[ 93.509453] x86_64_start_kernel+0x142/0x14f
[ 93.509462] start_cpu+0x14/0x14
[ 93.509469] ---[ end trace 2ca7dd51f09d19cd ]---
[ 93.509473] possible reason: unannotated irqs-off.
[ 93.509477] irq event stamp: 1437548
[ 93.509487] hardirqs last enabled at (1437548): [<ffffffffb504aafe>] kprobe_ftrace_handler+0x6e/0x1c0
[ 93.509495] hardirqs last disabled at (1437547): [<ffffffffb504aade>] kprobe_ftrace_handler+0x4e/0x1c0
[ 93.509503] softirqs last enabled at (1437532): [<ffffffffb50ff621>] _local_bh_enable+0x21/0x50
[ 93.509511] softirqs last disabled at (1437533): [<ffffffffb5100a3b>] irq_exit+0xcb/0xd0
--
Ricardo Nabinger Sanchez http://rnsanchez.wait4.org/
"You never learned anything by doing it right."
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: possible unannotated irqs-off
2017-02-14 19:28 possible unannotated irqs-off Ricardo Nabinger Sanchez
@ 2017-02-14 19:46 ` David Miller
2017-02-14 19:55 ` Ricardo Nabinger Sanchez
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2017-02-14 19:46 UTC (permalink / raw)
To: rnsanchez; +Cc: nic_swsd, netdev
From: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
Date: Tue, 14 Feb 2017 17:28:58 -0200
> [ 93.509167] ? jtcp_rcv_established+0x8e/0x2d0
> [ 93.509173] jtcp_rcv_established+0x8e/0x2d0
What are you using this TCP probe for? That's where the locking
problem is happening.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: possible unannotated irqs-off
2017-02-14 19:46 ` David Miller
@ 2017-02-14 19:55 ` Ricardo Nabinger Sanchez
2017-02-15 1:11 ` [PATCH net] tcp: tcp_probe: use spin_lock_bh() Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Nabinger Sanchez @ 2017-02-14 19:55 UTC (permalink / raw)
Cc: netdev
On Tue, Feb 14, 2017 at 5:46 PM, David Miller <davem@davemloft.net>
wrote:
> From: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
> Date: Tue, 14 Feb 2017 17:28:58 -0200
>
> > [ 93.509167] ? jtcp_rcv_established+0x8e/0x2d0
> > [ 93.509173] jtcp_rcv_established+0x8e/0x2d0
>
> What are you using this TCP probe for? That's where the locking
> problem is happening.
>
I just have a kernel build with most tracing/profiling things included
for the sake of LTTng and perf being as verbose as possible. It's all
vanilla, I haven't patched or modified any of the code.
My way of reproducing it is checking for updates for my Slackware64
system (i.e., "slackpkg update").
Cheers,
--
Ricardo Nabinger Sanchez http://rnsanchez.wait4.org/
"You never learned anything by doing it right."
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH net] tcp: tcp_probe: use spin_lock_bh()
2017-02-14 19:55 ` Ricardo Nabinger Sanchez
@ 2017-02-15 1:11 ` Eric Dumazet
2017-02-15 3:21 ` David Miller
2017-02-15 6:24 ` Stephen Hemminger
0 siblings, 2 replies; 6+ messages in thread
From: Eric Dumazet @ 2017-02-15 1:11 UTC (permalink / raw)
To: Ricardo Nabinger Sanchez, David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
tcp_rcv_established() can now run in process context.
We need to disable BH while acquiring tcp probe spinlock,
or risk a deadlock.
Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
---
net/ipv4/tcp_probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index f6c50af24a64737672f7ede2ff41158bfed5f1b4..3d063eb3784828b142874c92fd2db026bea0f3b3 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -117,7 +117,7 @@ static void jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
(fwmark > 0 && skb->mark == fwmark)) &&
(full || tp->snd_cwnd != tcp_probe.lastcwnd)) {
- spin_lock(&tcp_probe.lock);
+ spin_lock_bh(&tcp_probe.lock);
/* If log fills, just silently drop */
if (tcp_probe_avail() > 1) {
struct tcp_log *p = tcp_probe.log + tcp_probe.head;
@@ -157,7 +157,7 @@ static void jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
tcp_probe.head = (tcp_probe.head + 1) & (bufsize - 1);
}
tcp_probe.lastcwnd = tp->snd_cwnd;
- spin_unlock(&tcp_probe.lock);
+ spin_unlock_bh(&tcp_probe.lock);
wake_up(&tcp_probe.wait);
}
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH net] tcp: tcp_probe: use spin_lock_bh()
2017-02-15 1:11 ` [PATCH net] tcp: tcp_probe: use spin_lock_bh() Eric Dumazet
@ 2017-02-15 3:21 ` David Miller
2017-02-15 6:24 ` Stephen Hemminger
1 sibling, 0 replies; 6+ messages in thread
From: David Miller @ 2017-02-15 3:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: rnsanchez, netdev
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 14 Feb 2017 17:11:14 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> tcp_rcv_established() can now run in process context.
>
> We need to disable BH while acquiring tcp probe spinlock,
> or risk a deadlock.
>
> Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
Patch applied, thanks Eric.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] tcp: tcp_probe: use spin_lock_bh()
2017-02-15 1:11 ` [PATCH net] tcp: tcp_probe: use spin_lock_bh() Eric Dumazet
2017-02-15 3:21 ` David Miller
@ 2017-02-15 6:24 ` Stephen Hemminger
1 sibling, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2017-02-15 6:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ricardo Nabinger Sanchez, David Miller, netdev
On Tue, 14 Feb 2017 17:11:14 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> tcp_rcv_established() can now run in process context.
>
> We need to disable BH while acquiring tcp probe spinlock,
> or risk a deadlock.
>
> Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
Thanks. Also glad to see people are still using TCP probe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-15 6:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-14 19:28 possible unannotated irqs-off Ricardo Nabinger Sanchez
2017-02-14 19:46 ` David Miller
2017-02-14 19:55 ` Ricardo Nabinger Sanchez
2017-02-15 1:11 ` [PATCH net] tcp: tcp_probe: use spin_lock_bh() Eric Dumazet
2017-02-15 3:21 ` David Miller
2017-02-15 6:24 ` Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).