panic in __inet_hash

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 <[email protected]>
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.

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

From: Eric Dumazet <[email protected]>

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.

---
 net/ipv4/inet_connection_sock.c |    3 +++
 net/ipv4/inet_hashtables.c      |    3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

index bc5196ea1bdf..ab69da2d2a77 100644
@@ -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));

index 98ba03b6f87d..fcadb670f50b 100644
@@ -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) &&

Fixed the problem I as hiting.

From: Eric Dumazet <[email protected]>
Date: Wed, 06 Apr 2016 22:07:34 -0700

Applied, thanks Eric.