panic in __inet_hash

panic in __inet_hash

[David Ahern]

Rebased to top of tree a few minutes ago to test v6 of the multipath 
patch. I hitting a panic in __inet_hash:

[   17.264247] BUG: unable to handle kernel paging request at 
ffffffffffffffa8
[   17.265015] IP: [<ffffffff816e2b3c>] __inet_hash+0x11c/0x1c0
[   17.265015] PGD 1e07067 PUD 1e09067 PMD 0
[   17.265015] Oops: 0000 [#1] SMP
[   17.265015] Modules linked in:
[   17.265015] CPU: 0 PID: 1488 Comm: zebra Not tainted 4.6.0-rc1+ #5
[   17.265015] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 
04/01/2014
[   17.265015] task: ffff880011010800 ti: ffff880017bb0000 task.ti: 
ffff880017bb0000
[   17.265015] RIP: 0010:[<ffffffff816e2b3c>]  [<ffffffff816e2b3c>] 
__inet_hash+0x11c/0x1c0
[   17.265015] RSP: 0018:ffff880017bb3e48  EFLAGS: 00010293
[   17.265015] RAX: 0000000000000002 RBX: 0000000000000004 RCX: 
0000000000000002
[   17.265015] RDX: 0000000000000000 RSI: ffff880011010fa0 RDI: 
ffff880011010800
[   17.265015] RBP: ffff880017bb3e88 R08: ffffffff8282b080 R09: 
ffffffffffffff98
[   17.265015] R10: 0000000000000000 R11: 0000000000000000 R12: 
ffffffff82ea80c0
[   17.265015] R13: ffffffff82ea7f80 R14: 0000000000000000 R15: 
ffff88001b618000
[   17.265015] FS:  00007f947df9d740(0000) GS:ffff88001fc00000(0000) 
knlGS:0000000000000000
[   17.265015] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   17.265015] CR2: ffffffffffffffa8 CR3: 00000000179d7000 CR4: 
00000000000006f0
[   17.265015] Stack:
[   17.265015]  ffffffff82e95150 0000006e00000005 ffffffff8170b540 
ffff88001b618000
[   17.265015]  0000000000000000 0000000000000003 0000000000000000 
00000000ffffffff
[   17.265015]  ffff880017bb3ea0 ffffffff816e2c19 ffff88001b618000 
ffff880017bb3ec0
[   17.265015] Call Trace:
[   17.265015]  [<ffffffff8170b540>] ? udp4_seq_show+0x150/0x150
[   17.265015]  [<ffffffff816e2c19>] inet_hash+0x39/0x60
[   17.265015]  [<ffffffff816e44dd>] inet_csk_listen_start+0x9d/0xc0
[   17.265015]  [<ffffffff81719c2c>] inet_listen+0x9c/0xe0
[   17.265015]  [<ffffffff8166b5ae>] SyS_listen+0x4e/0x80
[   17.265015]  [<ffffffff81002eac>] do_syscall_64+0x5c/0x2b0
[   17.265015]  [<ffffffff8181829a>] entry_SYSCALL64_slow_path+0x25/0x25
[   17.265015] Code: 4b 54 9e ff 41 f6 c6 01 74 13 e9 88 00 00 00 4d 8b 
36 e8 38 54 9e ff 41 f6 c6 01 75 7a 4d 8d 4e 98 4d 39 cf 74 e9 41 0f b7 
47 10 <66> 41 39 46 a8 75 dd 41 0f b6 46 ab 89 c2 41 32 57 13 83 e2 20
[   17.265015] RIP  [<ffffffff816e2b3c>] __inet_hash+0x11c/0x1c0
[   17.265015]  RSP <ffff880017bb3e48>
[   17.265015] CR2: ffffffffffffffa8
[   17.265015] ---[ end trace d7340320507851f4 ]---



git bisect points to:
dsa@kenny:~/kernel-2.git$ git bisect bad
3b24d854cb35383c30642116e5992fd619bdc9bc is the first bad commit
commit 3b24d854cb35383c30642116e5992fd619bdc9bc
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 1 08:52:17 2016 -0700

     tcp/dccp: do not touch listener sk_refcnt under synflood

     When a SYNFLOOD targets a non SO_REUSEPORT listener, multiple
     cpus contend on sk->sk_refcnt and sk->sk_wmem_alloc changes.

     By letting listeners use SOCK_RCU_FREE infrastructure,
     we can relax TCP_LISTEN lookup rules and avoid touching sk_refcnt

     Note that we still use SLAB_DESTROY_BY_RCU rules for other sockets,
     only listeners are impacted by this change.

     Peak performance under SYNFLOOD is increased by ~33% :

     On my test machine, I could process 3.2 Mpps instead of 2.4 Mpps

     Most consuming functions are now skb_set_owner_w() and sock_wfree()
     contending on sk->sk_wmem_alloc when cooking SYNACK and freeing them.

     Signed-off-by: Eric Dumazet <edumazet@google.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>

:040000 040000 77d3f9ba3c3ec4c3443416f7536fe6d3ee9ec1a1 
b797845f7bbad79b5875bfa969ebfe9759c0b8b9 M	include
:040000 040000 0325378c93011f87012e5a6c064b09c2d59e052b 
32f90a3ec258f4625765c33d4718b2370e69e862 M	net

[PATCH net-next] tcp/dccp: fix inet_reuseport_add_sock()

[Eric Dumazet]

From: Eric Dumazet <edumazet@google.com>

David Ahern reported panics in __inet_hash() caused by my recent commit.

The reason is inet_reuseport_add_sock() was still using
sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
SO_REUSEPORT enabled listeners were causing an instant crash.

While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
flag, as it is inherited from the parent at clone time.

Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: David Ahern <dsa@cumulusnetworks.com>
---
 net/ipv4/inet_connection_sock.c |    3 +++
 net/ipv4/inet_hashtables.c      |    3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index bc5196ea1bdf..ab69da2d2a77 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -661,6 +661,9 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
 		inet_sk(newsk)->inet_sport = htons(inet_rsk(req)->ir_num);
 		newsk->sk_write_space = sk_stream_write_space;
 
+		/* listeners have SOCK_RCU_FREE, not the children */
+		sock_reset_flag(newsk, SOCK_RCU_FREE);
+
 		newsk->sk_mark = inet_rsk(req)->ir_mark;
 		atomic64_set(&newsk->sk_cookie,
 			     atomic64_read(&inet_rsk(req)->ir_cookie));
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 98ba03b6f87d..fcadb670f50b 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -439,10 +439,9 @@ static int inet_reuseport_add_sock(struct sock *sk,
 						     bool match_wildcard))
 {
 	struct sock *sk2;
-	struct hlist_nulls_node *node;
 	kuid_t uid = sock_i_uid(sk);
 
-	sk_nulls_for_each_rcu(sk2, node, &ilb->head) {
+	sk_for_each_rcu(sk2, &ilb->head) {
 		if (sk2 != sk &&
 		    sk2->sk_family == sk->sk_family &&
 		    ipv6_only_sock(sk2) == ipv6_only_sock(sk) &&

Re: [PATCH net-next] tcp/dccp: fix inet_reuseport_add_sock()

[David Ahern]

On 4/6/16 11:07 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> David Ahern reported panics in __inet_hash() caused by my recent commit.
>
> The reason is inet_reuseport_add_sock() was still using
> sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
> SO_REUSEPORT enabled listeners were causing an instant crash.
>
> While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
> flag, as it is inherited from the parent at clone time.
>
> Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: David Ahern <dsa@cumulusnetworks.com>
> ---

Fixed the problem I as hiting.

Tested-by: David Ahern <dsa@cumulusnetworks.com>

Re: [PATCH net-next] tcp/dccp: fix inet_reuseport_add_sock()

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Apr 2016 22:07:34 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> David Ahern reported panics in __inet_hash() caused by my recent commit.
> 
> The reason is inet_reuseport_add_sock() was still using
> sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
> SO_REUSEPORT enabled listeners were causing an instant crash.
> 
> While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
> flag, as it is inherited from the parent at clone time.
> 
> Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: David Ahern <dsa@cumulusnetworks.com>

Applied, thanks Eric.