断断续续插了一个 bpf sockmap 崩掉 aws k8s 的问题，症状是运行 skops bpf 把 passive established socket 加入 sockmap，几秒后整个节点的 pod + kubelet + containerd 都挂了。由于连锁反应极大，关键服务全部用 k8s 自举，我的权限很低只能在 debugging pod 里极限 hack，加上测试集群是共享的，为了不影响同事我只能每天在上班前半小时实验，光是看日志搞清楚关键进程的死亡顺序都麻了，而我怀着一颗“没有我查不出的bug🤬” 的决心终于查到了，是 6.1 内核的 bug，如果 listener socket 是 mptcp 但是 client socket 是普通 tcp，此时在 skops passive establish callback 把 conn socket 加入 sockmap 会导致 listener socket 进程被 kill -9，原因是 accept() syscall 的内核态 mptcp_stream_accept 函数会段错误崩掉
[ 231.864953] BUG: unable to handle page fault for address: 0000001400000110
[ 231.865884] #PF: supervisor read access in kernel mode
[ 231.866286] #PF: error_code(0x0000) - not-present page
[ 231.866649] PGD 1040a1067 P4D 1040a1067 PUD 0
[ 231.866883] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 231.867112] CPU: 2 PID: 398 Comm: srv Not tainted 6.1.155 #1
[ 231.867402] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 231.867861] RIP: 0010:mptcp_stream_accept+0xa6/0x190
不幸的是崩掉的进程是 aws-k8s-agent，节点上的万物起源，containerd/kubelet 发现 aws-k8s-agent connection refuse 会直接重启，然后全节点 pod 重启，太美了。其实应该说万幸崩掉的是 aws-k8s-agent 让我在测试阶段就暴露了问题，否则节点上某个使用 mptcp 的业务 app 直接进入 CrashLoopBackOff 而我一个做网络监控的 daemonset 浑然不觉还美滋滋觉得一切挺好😀
这个 6.1 的 bug 在最新的 patch version 6.1.155 依然存在，但在 6.14 里已经修复，我估计是无意识修复的，否则肯定会 backport。
sockmap bug 超多，虽然 cloudflare 吹得飞起 (https://www.usenix.org/system/files/srecon23emea-slides_sitnicki.pdf) ，但这已经是继 sk_msg_redirect (https://github.com/jschwinger233/bpf_msg_redirect_bug_reproducer) 之后我独立发现的第二个 bug 了，甚至我觉得比第一个还严重。再往前看，arthurchiao 老师发现的 https://arthurchiao.art/blog/tcp-requests-stuck-after-connection-established/ 也惨不忍睹，整个 sockmap 的可用性和可靠性就是一个悲剧，就这样硬上生产出事故不被公司起诉就不错了。。。
[ 231.864953] BUG: unable to handle page fault for address: 0000001400000110
[ 231.865884] #PF: supervisor read access in kernel mode
[ 231.866286] #PF: error_code(0x0000) - not-present page
[ 231.866649] PGD 1040a1067 P4D 1040a1067 PUD 0
[ 231.866883] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 231.867112] CPU: 2 PID: 398 Comm: srv Not tainted 6.1.155 #1
[ 231.867402] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 231.867861] RIP: 0010:mptcp_stream_accept+0xa6/0x190
不幸的是崩掉的进程是 aws-k8s-agent，节点上的万物起源，containerd/kubelet 发现 aws-k8s-agent connection refuse 会直接重启，然后全节点 pod 重启，太美了。其实应该说万幸崩掉的是 aws-k8s-agent 让我在测试阶段就暴露了问题，否则节点上某个使用 mptcp 的业务 app 直接进入 CrashLoopBackOff 而我一个做网络监控的 daemonset 浑然不觉还美滋滋觉得一切挺好😀
这个 6.1 的 bug 在最新的 patch version 6.1.155 依然存在，但在 6.14 里已经修复，我估计是无意识修复的，否则肯定会 backport。
sockmap bug 超多，虽然 cloudflare 吹得飞起 (https://www.usenix.org/system/files/srecon23emea-slides_sitnicki.pdf) ，但这已经是继 sk_msg_redirect (https://github.com/jschwinger233/bpf_msg_redirect_bug_reproducer) 之后我独立发现的第二个 bug 了，甚至我觉得比第一个还严重。再往前看，arthurchiao 老师发现的 https://arthurchiao.art/blog/tcp-requests-stuck-after-connection-established/ 也惨不忍睹，整个 sockmap 的可用性和可靠性就是一个悲剧，就这样硬上生产出事故不被公司起诉就不错了。。。