Welcome to the Black Parade

四周前，我发现一些系统上用户创建的 veth 会被修改 mac addr，所以我想，我需要一个工具去 trace netlink syscall，全局的那种，bpf-based，看看究竟是谁在调用 netlink syscall 修改我的 mac addr。 三周前，我意识到我不需要在 bpf 内核态解析 netlink，我只需要关注 strcut net_device *。你想到了什么？ pwru！我们可以从 btf 找出所有以 netdev 为参数的函数来追踪。 两周前，我反应过来，我需要的不只是 netdevsnoop ，而是一个通用的 Xsnoop 。是 X 不是 netdev！我糊了三个版本的 demo：jq + bash + bpftrace、python + bpftrace、 go + cilium/ebpf，但是没有一个达到我理想的状态。在“灵活”和“易用”上似乎难以找到一个折中，要么过于死板以至于完美适用一个场景却在另一场景不好用，要么过于灵活以至于动不动就要改代码。 一周前，我终于意识到，我需要的是 bpftrace-multi ，一个让我可以五分钟实现 pwru、十分钟定制化 pwru、分分钟完成 Xsnoop、顺便还有了 retsnoop 的功能。 虽然是个简单小项目，充满 bug，切代码块甚至用正则是 ^}$ ，但是我非常得意，已经帮我解决了好几个陈年 issue。 新年快乐！

妈的，我第一次知道一个正常的 TCP 四次挥手，双方发送的 FIN 包都会以 kfree_skb_reason(SKB_DROP_REASON_NOT_SPECIFIED) 结束生命周期。我之前不知道，我一看到 SKB_DROP 就直接定义为异常，然后开始惨无人道地深入内核 debug，结果白费力气！当场气死！

同事写了一本 ebpf children book: https://ebpf.io/books/buzzing-across-space-illustrated-childrens-guide-to-ebpf.pdf 什么布尔巴基学派。。。

超开心！ uprobe-multi 的最后一程终于也走完了，集成到了 cilium/ebpf ： https://github.com/cilium/ebpf/pull/1269 作者 jiri olsa 在 https://lore.kernel.org/bpf/[email protected]/ 里给出的测试数据是： Attaching current bpftrace to 1000 uprobes: # BPFTRACE_MAX_PROBES=100000 perf stat -e cycles,instructions \ ./bpftrace -e 'uprobe:./uprobe_multi:uprobe_multi_func_* { }, i:ms:1 { exit(); }' ... 126,666,390,509 cycles 29,973,207,307 instructions # 0.24 insn per cycle 85.284833554 seconds time elapsed Same bpftrace setup with uprobe_multi support: # perf stat -e cycles,instructions \ ./bpftrace -e 'uprobe:./uprobe_multi:uprobe_multi_func_* { }, i:ms:1 { exit(); }' ... 6,818,470,649 cycles 13,275,510,122 instructions # 1.95 insn per cycle 1.943269451 seconds time elapsed 85s -> 2s !!! 如果和 bpftime 相比，数据出处是 https://lpc.events/event/17/contributions/1639/attachments/1280/2585/userspace-ebpf-bpftime-lpc.pdf 第20页，bpftime 把 load time 性能提高了十倍，但是 uprobe multi 提升了不止十倍啊！ 大规模 uprobe 观测有救了！哭出声！我的破玩具项目似乎又可以捡起来了！

weaveworks 公司可能倒闭了。从 K8s 1.4 走过来的老云原神们应该读过各种 weave, flannel, calico 集成 docker 的文章，我至今都记得自己在微信公众号读着一篇篇容器网络的文章一头雾水的很多中午。 说起来，apache mesos 也有一家公司叫做 Mesosphere （后改名 D2iQ），于去年倒闭。Mesosphere 的故事更惨一点，它在 2018 年就已经看到 K8s won 的事实，然后转到 K8s 做产品，并且在 2020 年收到了谷歌几亿美元的收购 offer。但是他们拒绝了，然后倒闭了。 旧时代早就结束了，欢迎来到乐园。

和 Leon Hwang 一年一度面基 MoM 1. pwru 的未来：--trace-xdp, --trace-bpf-helpers, --trace-sk, --trace-kr，还有代码重构。当然只是口嗨，没人真的想动手做，除非被逼急了。 2. cilium 我的吐槽：一个 inline 八九个参数且没人能说得清每个参数都是干嘛的、一个函数500行过程式代码没人在意逻辑复杂度、每加一个功能就加一个 macro 和一堆 #ifdef 、没人敢也没人允许进行大规模重构、开发完一个新功能合并到main只是30%的工程量、剩下70%是backport到社区的3个分支+企业版6个分支+客户环境测试+解决backport过程中新出现的bug。cilium 早就过了可以爽写代码的阶段了，现在你往前走一步就要花更多精力让它不 break 其他功能。 3. 第一次给内核提交 patch 的注意事项。以及内核为啥经常会有这种类型 a 的指针并排一个类型 b 指针然后硬偏移转类型的写法，不能老老实实包一个结构体吗？ static const struct btf_array *btf_type_array(const struct btf_type *t) { return (const struct btf_array *)(t + 1); } 4. 我想找个做性能的工作，因为我至今都是性能白痴。现在你告诉我你机器上有个 redis cluster 而 redis-benchmark 的 p95 到 p99 有跳涨，我至今除了乱猜乱试都不知咋办，没有成体系的方法论。当然不可能有这种工作的，现在能保住收入就已经大吉大利了，轮不到挑三拣四。不然只能开公司。 5. Openresty Xray 在 2022 年春拒了两次我的简历，谢谢你。 6. bpftime 似乎比我以为的更有趣。其实我早就想过 ptrace 二进制改写，但是在 bpf 时代总觉得过于古典。 7. 这正好也是我昨天和奥格说起的，strace 的寿命和 bpf 平替版本，不管哪一头都费力不讨好，想去大干一场但细细一想工程量又让人直摇头。 8. 我最想要的 bpf network 功能： redirect skb from netdev to sk。当然这是不可能的。我最想要的二进制软件：IDA Pro。畅享 IDA 在逆向 xdp 和内核 debug 方面的用途，但是太贵了！ 9. 共识：不知道未来咋办。

二十年一刻 我在烦恼什么 （争取）杭州见！

我居然今天才知道，在节点上 curl 自己节点的 tcp 服务原来要走遍完整的 output + input 网络栈。 即，skb 先走 nf OUTPUT raw+ct+mangle+nat，然后再做路由决策 outbound iface 是 lo，然后继续走 netfilter POSTROUTING，到达 lo；接着 lo 接收 skb，甚至会走一遍 enqueue_to_backlog，然后 ingress 方向的内核栈，netfilter PREROUTING 和 INPUT 一个都跑不了。 我本来以为 ip_output() 里做完路由决策，看到是给自己的，那直接 ip_local_deliver() 就完了，直接 inet_lookup_listener() 找 sk 投递了事，没想到连 enqueue_to_backlog 这种性能大户都不跳过。 但是仔细一想也不是没有道理，不然如果我 curl localhost:8000 想做 NAT 就做不了了。想起 docker 容器劫持 DNS 其实就是 iptables OUTPUT 里做 DNAT，我又想通了。。。 所以 lo 上的 tc bpf 岂不是可以做很多坏事(

我急需让 curl --verbose 的输出自带 local port (source port)... 这么基础且重要的功能怎么会没有呢，在云原神 🤡SDN里，一个包的 dst host, dst port ,src host 都是常常被改的，比如经过 node port 进集群的南北流量就是如此，但是恰恰不改 src port，这使得我们追踪流量时唯一简单可靠的过滤就是用 src port。curl -w '%{local_port}' 确实可以输出 src port，但是当且仅当这个 curl 收到回复时，如果回复的包消失在了集群之中，curl 就啥都不输出了。 顺便 po 一个可能有用的 pcap filter: ip[2:2] > ((tcp[12:1] & 0xf0) >> 2) + ((ip[0] & 0xf) << 2)' 用来过滤有 tcp payload 的包。比如你 curl -v 看到 tcp 握手成功，curl 发出了 GET /，但是没有收到回复，用这个过滤来抓 http 包而忽略 tcp 握手和 ack。

Indeed 😭

今日弱智卡壳鉴赏 我要看 syscall tracepoint 的参数类型定义，我大致记得它在 /sys/kernel/debug/tracing/events/ 下面某个目录有个 format 文件，所以我 ls /sys/kernel/debug/tracing/events/ 然后用 Kitty 搜索 “syscall”，结果乳头。 我期待的结果是有个 syscalls 目录，然而没有，我就傻了，开始糊 raw_syscalls 这种弱类型 API 了，糊了半天觉得过于弱智，翻了翻黄黄老师 (mozillazg) 的博客，发现确实有 /sys/kernel/debug/tracing/events/syscalls/ 这个目录，而我上面没有发现是因为高亮显示的配色，对当前匹配居然用同色高亮。。。 “终端明明有输出但是我没看到” 导致在错误的方向上浪费几小时，这种眼瞎的事我也不是第一次了，什么终端折行啦，输出截断啦，现在又来一个高亮配色。很好，爱了。

Channel photo updated