Post #377

仔细检查了 bpf_get_stackid() 的实现，把之前一个放弃的方案捡了回来，解决了“关联 fentry event 和 kprobe event” 的问题，看起来已经没有任何技术障碍了，剩下的工程化只是体力活。 我要做的是观测 bpf program 内部的运行情况，这件事从入职第一天开始困扰我，我问同事，发邮件，查历年的 bpfconf，大家都只是说 "hey kprobe looks like it won't pass the address check in the check_kprobe_address_safe"，然后同事继续岁月静好，用大脑编译 bpf 程序，靠静态阅读理解黑洞，我这种弱智是根本跟不上的。 我在各种场合都说，我这么喜欢 tracing，是因为我菜；别人靠静态阅读代码能够发现 race，梳理所有分支，自动代入代码运行时状态和持久化数据，做出可靠正确的分析，但我不行。那种从一个 bpf map 里读一个数据出来，根据其中几个字段和 skb->cb / mark 的掩码来确定下一个分支的走向，在我这里简直就是一个巨大的谜团。对我来说这对“前置知识”的要求太高了，但似乎只有我遭遇了如此困难，其他人都能上手就把活干得又快又好，我做不到。 所以为了不被开除（说起来马上就要到被虾皮开除一周年了），我只能自己造出各种增加观测性的单手武器，用来填补自己平平无奇甚至中等偏下、愚昧不堪的智商。