Post #937

基础软件的 bug 真是让人很受伤。 bpftrace 今年六月合并的这个 https://github.com/bpftrace/bpftrace/commit/4e2f3c7934580dfd565468d797cdc6d023075f96 引入了一个 bug，如果 btf 里的函数参数是六个，则把这个函数错误地算作没有 btf 类型记录。这导致 bpftrace v0.42+ 总是报告不存在六参数的 fentry ``` # v0.23.5 ✅ $ ./bpftrace-v0.23.5 -lv f:tcp_recvmsg_locked fentry:vmlinux:tcp_recvmsg_locked struct sock * sk struct msghdr * msg size_t len int flags struct scm_timestamping_internal * tss int * cmsg_flags int retval # v0.24.1 💊 $ bpftrace-v0.24.1 -lv f:tcp_recvmsg_locked # nothing ``` 所以我一直以为 6.1 的 tcp_recvmsg_locked 被编译器玩坏了 btf 和 ksym，比如最臭名昭著的就是 finish_task_switch 这个重要的内核调度函数经常被编译器优化为 finish_task_switch.isra.0 | finish_task_switch.isra.0.cold，然而 btf 里记录的依然是 finish_task_switch，导致 fentry 无法 attach 这个函数。 我头脑风暴了几种方案用来解决这个问题，在 tcp_recvmsg 可以 fentry 但没有锁、要手动处理并发；在 tcp_recvmsg_locked 可以用 kretprobe 但要手动管理入参；性能要仔细审查，多两次 bpf map lookup+delete 大概就会 +1% cpu usage；或者用个巧妙的无锁方案。。。。同时思考那几个“小”bugs 是否根因是我没有处理好并发导致 iovec 读崩了。。。。心智负担++ 直到我在 arm 的 6.1 内核用 main 编译的 bpftrace-arm64 发现，怎么 arm 就有 tcp_recvmsg_locked 的 fentry? 内核版本不是一样的吗？ 然后我开始仔细手动检查 btf、kallsyms、tracing/available_filter_functions，发现 amd64 也应该是有的，我这才开始怀疑 bpftrace v0.24 有 bug、没能正确报告可用的 fentry。翻了一下发现三周前 Jordan 已经修了： https://github.com/bpftrace/bpftrace/pull/4701 ，目测在 bpftrace v0.24.2 就会包含这个修复。 回想起这个过程我就是无语，基础乳尖如果变得不可靠那整个技术选型、调查链路的基础都是错的，但人类就是会犯错，软件永远有 bug，工程师也不可能步步审查日常使用的基础软件是否报告的了错误的结果，只能依靠运气和工程警觉在未来某一步突然意识到“不对，这里怎么和我预期的不同，我要赶紧回头看看”，才有可能偶然纠正。 我真是又爱又恨。 BTW. bpftrace 虽然没有把 arm64 版本放入 release artifacts，但可以在 github action 里直接下载 main 的编译，乳头所示。