在新年来临之际写了一份频道介绍，建立阅读预期
本频道包含以上内容
本频道包含以上内容
最近一直在高强度依赖 socket cookie 构建模型，在考虑生命期（sk cookie 在 sk release 之后被复用吗）和数值分部（如果足够局部也许能很方便用 robin hood map 做性能优化）的时候看了一眼内核的 cookie 生成代码，很有趣🤔
核心思想是 likely(nesting == 1) 内层 + unlikely(val & 0xfff == 0) 外层的快路径：每个 CPU 分配 COOKIE_LOCAL_BATCH (4096) 个 per-cpu local ID，在非重入情况下直接 ++val 这个 local ID 作为 cookie 返回，零锁零原子指令，性能巨魔，只有在用完 4096 个 cookie 之后，走一次慢路径，用原子指令分配新的 4096 slot；或者在重入情况下走另一条原子指令直接返回。
（手机看下图缩进混乱警告
利用这个思想我们可以设计出极致性能的线程安全 ID 生成器，在用户态甚至更简单一点因为可以用 TLS thread local，或者更简单一点显式使用 thread local generator，比如 go 可以写成这样
在合适的场景下，如 “goroutine 总量不多但每个 goroutine 高并发地生成拳交唯一 ID”的场景下（其实和内核的 per cpu ptr 类似），这个算法完爆 atomic.Uint64 和 sync.Mutex
也就快了区区一百倍吧，逃（
static __always_inline u64 gen_cookie_next(struct gen_cookie *gc)
{
struct pcpu_gen_cookie *local = this_cpu_ptr(gc->local);
u64 val;
if (likely(local_inc_return(&local->nesting) == 1)) {
val = local->last;
if (__is_defined(CONFIG_SMP) &&
unlikely((val & (COOKIE_LOCAL_BATCH - 1)) == 0)) {
s64 next = atomic64_add_return(COOKIE_LOCAL_BATCH,
&gc->forward_last);
val = next - COOKIE_LOCAL_BATCH;
}
local->last = ++val;
} else {
val = atomic64_dec_return(&gc->reverse_last);
}
local_dec(&local->nesting);
return val;
}
核心思想是 likely(nesting == 1) 内层 + unlikely(val & 0xfff == 0) 外层的快路径：每个 CPU 分配 COOKIE_LOCAL_BATCH (4096) 个 per-cpu local ID，在非重入情况下直接 ++val 这个 local ID 作为 cookie 返回，零锁零原子指令，性能巨魔，只有在用完 4096 个 cookie 之后，走一次慢路径，用原子指令分配新的 4096 slot；或者在重入情况下走另一条原子指令直接返回。
（手机看下图缩进混乱警告
cpu0 cpu0
(used up) (val=4096*2+2048)
│ │
▼ ▼
┌─────────┬─────────┬─────────┐
│ 4096 │ 4096 │ 4096 │
└─────────┴─────────┴─────────┘
▲
│
cpu2
(val=4096+100)
利用这个思想我们可以设计出极致性能的线程安全 ID 生成器，在用户态甚至更简单一点因为可以用 TLS thread local，或者更简单一点显式使用 thread local generator，比如 go 可以写成这样
const Batch = 4096
type Global struct {
forward_last atomic.Uint64
}
type Local struct {
last uint64
_ [64 - 8]byte // Cacheline
forward_last *atomic.Uint64
}
func NewGlobal() *Global {
return &Global{}
}
func (g *Global) GetLocal() *Local {
return &Local{forward_last: &g.forward_last}
}
func (l *Local) NextID() uint64 {
val := l.last
if (val & (Batch - 1)) == 0 {
base := l.forward_last.Add(Batch) - Batch
val = base
}
val++
l.last = val
return val
}
在合适的场景下，如 “goroutine 总量不多但每个 goroutine 高并发地生成拳交唯一 ID”的场景下（其实和内核的 per cpu ptr 类似），这个算法完爆 atomic.Uint64 和 sync.Mutex
$ taskset -c 1,2,4 ./go_nextid.test -test.bench=.
cpu: Intel(R) Core(TM) Ultra 7 155U
BenchmarkNextID_Local-3 1000000000 0.2906 ns/op
BenchmarkNextID_Local_Fixed/G=16-3 1000000000 0.1252 ns/op
BenchmarkNextID_Local_Fixed/G=128-3 1000000000 0.1352 ns/op
BenchmarkNextID_Local_Fixed/G=1024-3 1000000000 0.1436 ns/op
BenchmarkAtomic_Add-3 316950108 3.804 ns/op
BenchmarkAtomic_Add_Fixed/G=16-3 56497480 21.83 ns/op
BenchmarkAtomic_Add_Fixed/G=128-3 54910852 21.90 ns/op
BenchmarkAtomic_Add_Fixed/G=1024-3 55797655 22.03 ns/op
BenchmarkMutex-3 100000000 10.78 ns/op
BenchmarkMutex_Fixed/G=16-3 15218778 85.92 ns/op
BenchmarkMutex_Fixed/G=128-3 12138136 103.6 ns/op
BenchmarkMutex_Fixed/G=1024-3 10970743 106.1 ns/op
也就快了区区一百倍吧，逃（
发现我最爱的 UNP 关于 tcp socket 如何处理 RST 的描述居然是错的。Linux 处理 tcp reset 是看链接状态的：
所以有以下三种典型情况：
1. 主动连接方发送 tcp syn，对端并没有监听目标端口，返回 tcp reset，connect syscall 返回 ECONNREFUSED 即 connection refused.
2. 主动关闭方先发一个 fin，被动关闭方收到 fin 之后继续发送 tcp payload，这是合法的 tcp 半关闭单向通道；被动关闭方第一次 send 会成功发送，但主动端如果已经 **全关闭**，会返回 tcp reset；被动方收到 reset 后第二次 send 会返回 EPIPE 并伴随 SIGPIPE。
3. 主动关闭方由于一些原因（linger、 非空 recvbuf on close）直接发送 tcp reset，被动方的 send syscall 会直接返回 ECONNRESET。write syscall 也会 ECONNRESET，但要注意 tcp reset 也是入 recvbuf 的，必须先消费掉 payload。
UNP 只描述了场景2，但是 1 和 3 其实也很常见，而且 2 和 3 很容易混淆，本频道之前讨论过几次 tcp reset / SIGPIPE 就完全稀里糊涂。虽然区分出来好像也没特别大的帮助，但给人一种很专业的样子
void tcp_reset(struct sock *sk)
{
trace_tcp_receive_reset(sk);
/* We want the right error as BSD sees it (and indeed as we do). */
switch (sk->sk_state) {
case TCP_SYN_SENT:
sk->sk_err = ECONNREFUSED;
break;
case TCP_CLOSE_WAIT:
sk->sk_err = EPIPE;
break;
case TCP_CLOSE:
return;
default:
sk->sk_err = ECONNRESET;
}
...
所以有以下三种典型情况：
1. 主动连接方发送 tcp syn，对端并没有监听目标端口，返回 tcp reset，connect syscall 返回 ECONNREFUSED 即 connection refused.
2. 主动关闭方先发一个 fin，被动关闭方收到 fin 之后继续发送 tcp payload，这是合法的 tcp 半关闭单向通道；被动关闭方第一次 send 会成功发送，但主动端如果已经 **全关闭**，会返回 tcp reset；被动方收到 reset 后第二次 send 会返回 EPIPE 并伴随 SIGPIPE。
3. 主动关闭方由于一些原因（linger、 非空 recvbuf on close）直接发送 tcp reset，被动方的 send syscall 会直接返回 ECONNRESET。write syscall 也会 ECONNRESET，但要注意 tcp reset 也是入 recvbuf 的，必须先消费掉 payload。
UNP 只描述了场景2，但是 1 和 3 其实也很常见，而且 2 和 3 很容易混淆，本频道之前讨论过几次 tcp reset / SIGPIPE 就完全稀里糊涂。虽然区分出来好像也没特别大的帮助，但给人一种很专业的样子
继续 golang 数码世界大冒险，上次说到 https://go.dev/play/p/kfAeED2Q2mJ 这个程序里的 callback 版本和 direct 版本有巨大的性能差距，群友 Bo 指出这是由于 literal func 导致的，把闭包移动到循环外避免每次循环都创建就可以了：
That's a very sharp observation!
随便做一次 perf record -g + perf report --stdio，发现热点栈是这样的：
稍微敏锐一点应该都能注意到那个 80% runtime.newobject 不对劲，用 gdb disas/m 一下 main.consumeCallback 可以看到:
说明确实是每次循环都创建了闭包。
但是把闭包移出循环之外，再做一次 perf record，发现依然有 80% 的 runtime.newobject
这个闭包看名字就知道是来自：
想办法把这个闭包初始化 hack 掉，发现把 ring 显式传入而不是 capture、并且直接 forward closure 而不新创建 closure 就可以了：
这下性能直接提升了十倍，从 40 Mops/s -> 400+ Mops/s，看 perf record 里也不再有 runtime.newobject，全是干净的业务代码栈：
我觉得教训还是比较深刻的，我之前确实不知道 go 闭包有这么悲痛的性能，真就随地大小 closure。但 perf 方法论依然可以让我们在不具备相关知识储备的情况下重新发现这个问题，perf 好！
@@ -65,12 +65,13 @@ func consumeCallback(ring eventRing) (int, uint64) {
ops int
digest uint64
)
+ f := func(chunk []byte) error {
+ digest += binary.LittleEndian.Uint64(chunk[:8])
+ ops++
+ return nil
+ }
for range totalItems {
- err := readFunc(ring, func(chunk []byte) error {
- digest += binary.LittleEndian.Uint64(chunk[:8])
- ops++
- return nil
- })
+ err := readFunc(ring, f)
if err != nil {
panic(err)
}That's a very sharp observation!
随便做一次 perf record -g + perf report --stdio，发现热点栈是这样的：
99.62% 0.00% purego_callback purego_callback_repro [.] runtime.goexit.abi0
|
---runtime.goexit.abi0
runtime.main
main.main
|
--98.72%--main.consumeCallback2
|
|--79.03%--runtime.newobject
稍微敏锐一点应该都能注意到那个 80% runtime.newobject 不对劲，用 gdb disas/m 一下 main.consumeCallback 可以看到:
0x000000000049cb68 <+104>: call 0x413f00 <runtime.newobject>
0x000000000049cb6d <+109>: lea 0x14c(%rip),%rcx # 0x49ccc0 <main.consumeCallback.func1>
说明确实是每次循环都创建了闭包。
但是把闭包移出循环之外，再做一次 perf record，发现依然有 80% 的 runtime.newobject
0x000000000049cbc0 <+192>: call 0x413f00 <runtime.newobject>
0x000000000049cbc5 <+197>: lea 0x94(%rip),%rcx # 0x49cc60 <main.consumeCallback.readFunc.readWithPoll.consumeCallback.readFunc.func2.func3>
这个闭包看名字就知道是来自：
func readFunc(ring eventRing, f func(chunk []byte) error) error {
return readWithPoll(func() error {
return ring.readRecordFunc(func(chunk []byte) error {
return f(chunk)
})
})
}想办法把这个闭包初始化 hack 掉，发现把 ring 显式传入而不是 capture、并且直接 forward closure 而不新创建 closure 就可以了：
@@ -24,12 +24,12 @@ func (r *Ring) readRecordFunc(f func(chunk []byte) error) error {
return f(r.data[:chunkBytes])
}
-func readWithPoll(read func() error) error {
+func readWithPoll(ring eventRing, read func() error) error {
return read()
}
func readInto(ring eventRing, rec *[chunkBytes]byte) error {
- return readWithPoll(func() error {
+ return readWithPoll(ring, func() error {
return ring.readRecordFunc(func(chunk []byte) error {
copy(rec[:], chunk)
return nil
@@ -38,10 +38,8 @@ func readInto(ring eventRing, rec *[chunkBytes]byte) error {
}
func readFunc(ring eventRing, f func(chunk []byte) error) error {
- return readWithPoll(func() error {
- return ring.readRecordFunc(func(chunk []byte) error {
- return f(chunk)
- })
+ return readWithPoll(ring, func() error {
+ return ring.readRecordFunc(f)
})
}这下性能直接提升了十倍，从 40 Mops/s -> 400+ Mops/s，看 perf record 里也不再有 runtime.newobject，全是干净的业务代码栈：
|--97.11%--main.main
| |
| |--94.43%--main.consumeCallback
| | |
| | |--48.08%--main.(*Ring).readRecordFunc
| | | |
| | | --33.64%--main.consumeCallback.func1
我觉得教训还是比较深刻的，我之前确实不知道 go 闭包有这么悲痛的性能，真就随地大小 closure。但 perf 方法论依然可以让我们在不具备相关知识储备的情况下重新发现这个问题，perf 好！
考虑下面的简单 go 程序，其中 bpf.o 编译自任意一个简单的需要 CO-RE relocation 的 kprobe 此处就不展示了：
用 ps -e -o pid,rss,comm 很惊讶地发现这个进程在强制 gc 后依然占用了 50+M 的 RSS，泄！明明所有 stack var 都被我 close + nil 了！
用 go tool pprof http://127.0.0.1:6060/debug/pprof/heap?gc=1 看一下前五 heap objects:
😅虽然不知道怎么回事，但貌似是 BTF 读进内存后就没 gc 回去，真是谢谢您了。
虽然 pprof/heap 提供这层信息已经很屌了，然而接下来的路依然不好走，我能想到的办法是用 tree 命令看调用栈，然后对每一层调用都用 list/web 仔细检查源码。
比如对于泄露了 20M 的 github.com/cilium/ebpf/btf.readAndInflateTypes， tree 可以看到其中一层栈是：
然后用 weblist 检查 LoadKernelSpec 的源码
看到源码里
注意到 spec := loadKernelSpec() 这一步 alloc 了 45M 内存并返回，但是在返回之前给全局变量 kernelBTF.kernel = spec 设置了一个引用，正是这个引用导致了之后无法 gc 一大坨内存。喜欢吗😀
以上步骤还是太苦了，尤其是还要人肉找到全局变量的引用，但凡瞎一点就错过了，任劳任怨的 LLM 此时就站了出来。
如果思路再打开一点，相信 golang gc 没有这么恶性的 bug😀 ，一定是 lib 自己内部有全局变量拿了一份引用导致无法 gc，那么可以直接去看 elf 里的 bss/data segment 里长得像
也能直接找到这个全局变量。
但总得来说我还是觉得有点蛋疼，不知道有没有更好的方法和工具，请各位 golang experts 再次伸出
func main() {
spec, _ := ebpf.LoadCollectionSpec("bpf.o")
coll, _ := ebpf.NewCollection(spec)
coll.Close()
coll = nil
spec = nil
runtime.GC()
debug.FreeOSMemory()
log.Fatal(http.ListenAndServe("localhost:6060", nil))
}用 ps -e -o pid,rss,comm 很惊讶地发现这个进程在强制 gc 后依然占用了 50+M 的 RSS，泄！明明所有 stack var 都被我 close + nil 了！
用 go tool pprof http://127.0.0.1:6060/debug/pprof/heap?gc=1 看一下前五 heap objects:
(pprof) top 5
flat flat% sum% cum cum%
18.17MB 38.00% 38.00% 22.68MB 47.42% github.com/cilium/ebpf/btf.readAndInflateTypes
17MB 35.55% 73.55% 17MB 35.55% github.com/cilium/ebpf/btf.indexTypes
4.50MB 9.42% 82.97% 4.50MB 9.42% github.com/cilium/ebpf/btf.readAndInflateTypes.func2
3MB 6.27% 89.24% 3MB 6.27% bufio.(*Scanner).Text (inline)
2.64MB 5.52% 94.76% 5.64MB 11.79% github.com/cilium/ebpf/btf.readStringTable
😅虽然不知道怎么回事，但貌似是 BTF 读进内存后就没 gc 回去，真是谢谢您了。
虽然 pprof/heap 提供这层信息已经很屌了，然而接下来的路依然不好走，我能想到的办法是用 tree 命令看调用栈，然后对每一层调用都用 list/web 仔细检查源码。
比如对于泄露了 20M 的 github.com/cilium/ebpf/btf.readAndInflateTypes， tree 可以看到其中一层栈是：
(pprof) tree github.com/cilium/ebpf/btf.readAndInflateTypes
[...]
22.68MB 100% | github.com/cilium/ebpf/btf.LoadKernelSpec
0 0% 47.42% 22.68MB 47.42% | github.com/cilium/ebpf/btf.loadKernelSpec
22.68MB 100% | github.com/cilium/ebpf/btf.loadRawSpec
然后用 weblist 检查 LoadKernelSpec 的源码
(pprof) weblist github.com/cilium/ebpf/btf.LoadKernelSpec
看到源码里
35 . . func LoadKernelSpec() (*Spec, error) {
36 . . kernelBTF.RLock()
37 . . spec := kernelBTF.kernel
38 . . kernelBTF.RUnlock()
39 . .
40 . . if spec == nil {
41 . . kernelBTF.Lock()
42 . . defer kernelBTF.Unlock()
43 . .
44 . . spec = kernelBTF.kernel
45 . . }
46 . .
47 . . if spec != nil {
48 . . return spec.Copy(), nil
49 . . }
50 . .
51 . 45.31MB spec, _, err := loadKernelSpec()
52 . . if err != nil {
53 . . return nil, err
54 . . }
55 . .
56 . . kernelBTF.kernel = spec
57 . . return spec.Copy(), nil
58 . . }注意到 spec := loadKernelSpec() 这一步 alloc 了 45M 内存并返回，但是在返回之前给全局变量 kernelBTF.kernel = spec 设置了一个引用，正是这个引用导致了之后无法 gc 一大坨内存。喜欢吗
以上步骤还是太苦了，尤其是还要人肉找到全局变量的引用，但凡瞎一点就错过了，任劳任怨的 LLM 此时就站了出来。
如果思路再打开一点，相信 golang gc 没有这么恶性的 bug
cilium/ebpf/*btf* 的符号$ objdump -t ./main | grep '\.bss\|\.data' | grep -i 'cilium/ebpf.*btf'
[...]
0000000000afda20 g O .bss 0000000000000028 github.com/cilium/ebpf/btf.kernelBTF
也能直接找到这个全局变量。
但总得来说我还是觉得有点蛋疼，不知道有没有更好的方法和工具，请各位 golang experts 再次伸出
把自己用过的网络编程方面的 bpf 梳理了一下(tx 方向的 tcp only)，太多细节完全无文档，这就是
[1] cgroup/sock_create 虽然是很好的 hook 用来关联用户态进程和 socket，但是它只能用在主动连接的 tcp socket，因为 passive establish tcp socket 创建时刻是三次握手完成时的内核态，强行读取 struct task 读到的可能是软中断侵入的用户态进程而非最终 accept 的用户态进程。 bpf programming 心智负担高，这是第一条：同一个 bpf prog 可能在不同上下文被触发。
[2] cgroup/connect4 是很好的 per-socket hook 点，此处可以修改 dst ip （LB DNAT 逻辑）、修改 SO_MARK 保证之后的网络包都有特殊的 mark、注入 setsockopt 强绑 ifindex 做路由强选……在之后还会有很多时刻可以用来“重定向流量”，比方用作透明代理流量劫持，但之后的做法都叫做 per-packet，性能优劣一目了然。
[3] skops 除了可以注入 tcp toa 等 optional header 之外，在高版本内核里的还有不少很好的观测性 hook 弥补了传统 tcp info (ss) 的局限，比如 BPF_SOCK_OPS_TSTAMP_SND_SW_CB 用来观测 tcp 在 kernel stack 的 latency。
[4] sk_msg bpf 的 bpf_msg_redirect_hash 虽然实现了 local -> local 的 tcp 流量在三次握手后直接像 pipe 一样发送字节流而完全 bypass tcp stack，看起来美好，但由于 sockmap 的海量恶性 bug，目前慎用，kernel panic。
[5] cgroup_skb/egress 肯定不是唯一可以同时拿到 sk 和 skb 的 bpf，比方说我们可以在 tc/egress 里读取 skb->sk，但它是唯一的单次 attach (cgroup v2 root) 就能全局触发的 bpf，而 tc/egress 需要逐 netdev attach，也要注意 net namespace；我们也可以在任何一个 skb context 的 tracepoint 里 CORE_READ(skb, sk)，但是这些 hook 很难高性能读全 GSO-ed skb payload（非线性区），而 cgroup_skb 可以通过 bpf_load_skb_bytes 读到所有的非线性区。这是一个被低估的 bpf hook，有很多想象空间。
[6] lwt_xmit 是另一个可以用来做流量重定向的 hook，但它相比其他 hook 来说已经比较晚了，而且它是 attach 在 routing 上，很难用，我的看法是不要用。
关于顺序和 context 的额外注解：
1. 顺序隐含了很多信息，比方说 nf postrouting > cgroup_skb/egress > arp，这个顺序暗含了：
1.a. cgroup_skb bpf 看到的是 nf NAT 过的 skb，在此时收集观测性数据时用 sk 的 tuple 还是 skb 的 tuple，不同需求有不同设计。
1.b. 还没发生二层解析，skb->data 里不可能有 mac 地址。
1.c. 这个 hook 在 tcp retrans 之后，意味着可能看到重试的 tcp segment，如果要做 seg/ack 统计分析就要重组的准备。
1.d. 这个 hook 只是网络包在网络栈的一个中间步骤，在这里看到一个 tcp 请求不代表它发出去了。
2. user context vs kernel context
我们想要在 tc/egress 上抓 “指定 pid 进程的流量”，第一反应应该是在其中调用 bpf_get_current_task() 或者 bpf_get_current_pid_tgid()，但是这只有在 tc bpf 运行在用户态上下文时才成立，而 tc bpf 如果处理的是 tcp retrans 重试流量，一定处于软中断内核态上下文，那 bpf_get_current_pid_tgid 读到的就是被侵入的 pid。
3. irqsoft enable vs disable (local_bh_disable)
我们想要在在 BPF_PROG_TYPE_NETFILTER bpf 里做一些简单的统计，决定用 percpu_map 避免 CAS 原子操作的性能问题，这在 xdp 和 tc bpf 里很常见，因为 tc bpf 关闭了软中断 local_bh_disable，所以直接非原子地加减 percpu 变量不会被抢占和重入，但在 BPF_PROG_TYPE_NETFILTER 等大部分没有关闭软中断的 bpf 就不行了。
其实 rx 方向还要更复杂一些，因为有 xdp, sk_lookup, sk_reuseport 等更多的 bpf 类型，心智负担更高，但我已经打开了 Diablo2 继续我的专家模式圣骑士了。老板都辞职了我上个屁班😀
[1] cgroup/sock_create 虽然是很好的 hook 用来关联用户态进程和 socket，但是它只能用在主动连接的 tcp socket，因为 passive establish tcp socket 创建时刻是三次握手完成时的内核态，强行读取 struct task 读到的可能是软中断侵入的用户态进程而非最终 accept 的用户态进程。 bpf programming 心智负担高，这是第一条：同一个 bpf prog 可能在不同上下文被触发。
[2] cgroup/connect4 是很好的 per-socket hook 点，此处可以修改 dst ip （LB DNAT 逻辑）、修改 SO_MARK 保证之后的网络包都有特殊的 mark、注入 setsockopt 强绑 ifindex 做路由强选……在之后还会有很多时刻可以用来“重定向流量”，比方用作透明代理流量劫持，但之后的做法都叫做 per-packet，性能优劣一目了然。
[3] skops 除了可以注入 tcp toa 等 optional header 之外，在高版本内核里的还有不少很好的观测性 hook 弥补了传统 tcp info (ss) 的局限，比如 BPF_SOCK_OPS_TSTAMP_SND_SW_CB 用来观测 tcp 在 kernel stack 的 latency。
[4] sk_msg bpf 的 bpf_msg_redirect_hash 虽然实现了 local -> local 的 tcp 流量在三次握手后直接像 pipe 一样发送字节流而完全 bypass tcp stack，看起来美好，但由于 sockmap 的海量恶性 bug，目前慎用，kernel panic。
[5] cgroup_skb/egress 肯定不是唯一可以同时拿到 sk 和 skb 的 bpf，比方说我们可以在 tc/egress 里读取 skb->sk，但它是唯一的单次 attach (cgroup v2 root) 就能全局触发的 bpf，而 tc/egress 需要逐 netdev attach，也要注意 net namespace；我们也可以在任何一个 skb context 的 tracepoint 里 CORE_READ(skb, sk)，但是这些 hook 很难高性能读全 GSO-ed skb payload（非线性区），而 cgroup_skb 可以通过 bpf_load_skb_bytes 读到所有的非线性区。这是一个被低估的 bpf hook，有很多想象空间。
[6] lwt_xmit 是另一个可以用来做流量重定向的 hook，但它相比其他 hook 来说已经比较晚了，而且它是 attach 在 routing 上，很难用，我的看法是不要用。
关于顺序和 context 的额外注解：
1. 顺序隐含了很多信息，比方说 nf postrouting > cgroup_skb/egress > arp，这个顺序暗含了：
1.a. cgroup_skb bpf 看到的是 nf NAT 过的 skb，在此时收集观测性数据时用 sk 的 tuple 还是 skb 的 tuple，不同需求有不同设计。
1.b. 还没发生二层解析，skb->data 里不可能有 mac 地址。
1.c. 这个 hook 在 tcp retrans 之后，意味着可能看到重试的 tcp segment，如果要做 seg/ack 统计分析就要重组的准备。
1.d. 这个 hook 只是网络包在网络栈的一个中间步骤，在这里看到一个 tcp 请求不代表它发出去了。
2. user context vs kernel context
我们想要在 tc/egress 上抓 “指定 pid 进程的流量”，第一反应应该是在其中调用 bpf_get_current_task() 或者 bpf_get_current_pid_tgid()，但是这只有在 tc bpf 运行在用户态上下文时才成立，而 tc bpf 如果处理的是 tcp retrans 重试流量，一定处于软中断内核态上下文，那 bpf_get_current_pid_tgid 读到的就是被侵入的 pid。
3. irqsoft enable vs disable (local_bh_disable)
我们想要在在 BPF_PROG_TYPE_NETFILTER bpf 里做一些简单的统计，决定用 percpu_map 避免 CAS 原子操作的性能问题，这在 xdp 和 tc bpf 里很常见，因为 tc bpf 关闭了软中断 local_bh_disable，所以直接非原子地加减 percpu 变量不会被抢占和重入，但在 BPF_PROG_TYPE_NETFILTER 等大部分没有关闭软中断的 bpf 就不行了。
其实 rx 方向还要更复杂一些，因为有 xdp, sk_lookup, sk_reuseport 等更多的 bpf 类型，心智负担更高，但我已经打开了 Diablo2 继续我的专家模式圣骑士了。老板都辞职了我上个屁班
啥玩意儿？打出来一个 20-17 居然价值 560￥？
众所周知，不带复杂参数的 perf record -g 可以采样 cpu 热点栈，当 pmc overflow 时候触发 pmu 中断，收集栈回溯，然后可以生成火焰图。
不过 perf record 其实支持更细粒度的事件，比方说，perf stat -ddd 看到 LLC-load-misses 很高的话，可以考虑针对性地收集一下 L3 miss 的火焰图。先用 perf list pmu 找到事件是 memory_activity.stalls_l3_miss，然后 perf record -g -e memory_activity.stalls_l3_miss，也很好用。
在这个百年未有之大变局时代， pmu 中断回调其实还支持 bpf，虽然 perf 本身支持不够，但是 bpftrace 有支持一部分，比如 bpftrace -e 'hardware:cache-misses:1e6 {}' 在每 1e6 次 cache-miss 时运行我们自定义的 bpftrace 脚本。一个简单的例子是我们要 profiling 多个进程，但 perf record -p $PID 不支持复杂的过滤，那可编程的 perf 采样就很重要了。
但 bpftrace 只支持很少部分的 hardware 事件，如果我们想在更细的 pmu 事件注册 bpf，比如 memory_activity.stalls_l3_miss，那就没有办法： https://github.com/bpftrace/bpftrace/issues/45
而且 bpftrace 的 profiling 很干巴，不支持复杂的 perf attributes: https://github.com/bpftrace/bpftrace/issues/3360
我在很长岁月里都没有好的解决办法，只能通过编程的方式，手动调用 perf_event_open syscall，手动调配各种参数，塞入 bpf prog fd，来实现复杂的 perf，不好用。
但是！
最近我学到 pmu 中断其实是 nmi 事件，而现代内核正好有 nmi tracepoint，我们可以一边用 perf record 触发 TopdownL3/L4 级别的底层 pmu，一边用 bpftrace attach tracepoint:nmi:nmi_handler 来进行复杂的过滤和观测。
比方说先在 terminal 1 运行
然后在 terminal 2 运行
就可以完成这个编程采样接力。
虽然 nmi_handler 拿不到直接的 pt_regs，但可以通过 bpf_get_current_task() + bpf_task_pt_regs() 手动获取，手搓也不复杂，毕竟只是在 task_struct->stack：
由此我们就可以委曲求全，曲线爱国，间接对底层 pmu 实现进行自定义采样，对于 python 虚拟机这种需要从 struct PyFrameObject 手动抠 python stack 的编程化采样来得正是时候
不过 perf record 其实支持更细粒度的事件，比方说，perf stat -ddd 看到 LLC-load-misses 很高的话，可以考虑针对性地收集一下 L3 miss 的火焰图。先用 perf list pmu 找到事件是 memory_activity.stalls_l3_miss，然后 perf record -g -e memory_activity.stalls_l3_miss，也很好用。
在这个百年未有之大变局时代， pmu 中断回调其实还支持 bpf，虽然 perf 本身支持不够，但是 bpftrace 有支持一部分，比如 bpftrace -e 'hardware:cache-misses:1e6 {}' 在每 1e6 次 cache-miss 时运行我们自定义的 bpftrace 脚本。一个简单的例子是我们要 profiling 多个进程，但 perf record -p $PID 不支持复杂的过滤，那可编程的 perf 采样就很重要了。
但 bpftrace 只支持很少部分的 hardware 事件，如果我们想在更细的 pmu 事件注册 bpf，比如 memory_activity.stalls_l3_miss，那就没有办法： https://github.com/bpftrace/bpftrace/issues/45
而且 bpftrace 的 profiling 很干巴，不支持复杂的 perf attributes: https://github.com/bpftrace/bpftrace/issues/3360
我在很长岁月里都没有好的解决办法，只能通过编程的方式，手动调用 perf_event_open syscall，手动调配各种参数，塞入 bpf prog fd，来实现复杂的 perf，不好用。
但是！
最近我学到 pmu 中断其实是 nmi 事件，而现代内核正好有 nmi tracepoint，我们可以一边用 perf record 触发 TopdownL3/L4 级别的底层 pmu，一边用 bpftrace attach tracepoint:nmi:nmi_handler 来进行复杂的过滤和观测。
比方说先在 terminal 1 运行
bpftrace -e 't:nmi:nmi_handler /comm == "a.out"/
{
printf("%s%s\n", kstack, ustack);
}
然后在 terminal 2 运行
perf record -F 99 -e memory_activity.stalls_l3_miss -- ./a.out
就可以完成这个编程采样接力。
虽然 nmi_handler 拿不到直接的 pt_regs，但可以通过 bpf_get_current_task() + bpf_task_pt_regs() 手动获取，手搓也不复杂，毕竟只是在 task_struct->stack：
#define task_pt_regs(task) \
({ \
unsigned long __ptr = (unsigned long)task_stack_page(task); \
__ptr += THREAD_SIZE - TOP_OF_KERNEL_STACK_PADDING; \
((struct pt_regs *)__ptr) - 1; \
})
由此我们就可以委曲求全，曲线爱国，间接对底层 pmu 实现进行自定义采样，对于 python 虚拟机这种需要从 struct PyFrameObject 手动抠 python stack 的编程化采样来得正是时候
群友 @ssfdust 沿着这个思路做了一些深入探索，发现不如直接把敏感 syscall 单独放到 fork 新进程里运行，这样被杀的是子进程，但是主进程依然享受副作用。他用 ds v4 pro 基本复现出来了 (https://github.com/ssfdust/cve-bpf-deny/)，证明了
我虽然还没细看，但是有个技术细节还挺有趣，也是我最近龟速学习 Linux v0.11 源码想到的：众所周知信号的传递是异步的，除非是自己给自己发信号，不过这是为什么呢？这是因为 (v0.11 的) Linux 只在一个时间点传递信号： ret_from_sys_call，在执行完 syscall 逻辑之后（或者是中断之后），iret 弹回用户态之前，检查 task->signal 是否有 pending 信号，有的话 call do_signal。换句话说，如果一个用户态进程在内核态处于 R 状态并且没有被中断，那信号会被延迟到 syscall 结束时才执行，这导致整个 syscall 的副作用已经完全产生，因此我们可以想办法让这个副作用通过共享内存保留下来。
大多数教材讲信号传递都会强调其传递的不可知性，我觉得反而神秘化了，不如就拿着 Linux 0.11 好好讲讲信号传递的 checkpoint，“更稳
bpftrace -e 'k:adae_bind,* {signal(9)}' 不是安全的防御手段。我虽然还没细看，但是有个技术细节还挺有趣，也是我最近龟速学习 Linux v0.11 源码想到的：众所周知信号的传递是异步的，除非是自己给自己发信号，不过这是为什么呢？这是因为 (v0.11 的) Linux 只在一个时间点传递信号： ret_from_sys_call，在执行完 syscall 逻辑之后（或者是中断之后），iret 弹回用户态之前，检查 task->signal 是否有 pending 信号，有的话 call do_signal。换句话说，如果一个用户态进程在内核态处于 R 状态并且没有被中断，那信号会被延迟到 syscall 结束时才执行，这导致整个 syscall 的副作用已经完全产生，因此我们可以想办法让这个副作用通过共享内存保留下来。
大多数教材讲信号传递都会强调其传递的不可知性，我觉得反而神秘化了，不如就拿着 Linux 0.11 好好讲讲信号传递的 checkpoint，“更稳