在使用 bpf 追踪内核函数的时候，通常需要对函数参数进行过滤。 如果使用 bpftrace，可以很方便地在脚本里指定过滤条件；但 bpftrace 依赖 LLVM，很多时

设备层抓包？不就是 tcpdump 嘛。缺点是，-i any 时无法抓到各个 netns 内的网络包。 netif_receive_skb 和 net_dev_queue 这 2 个 tracepoint 呢？好，能抓到所有 netns 内的网络包了。但， tracepoint bpf prog 不支持 bpf_skb_output help

在使用 curl、telnet 等工具排查问题的时候，如果想要知道当前的连接信息，在现有的工具集里，是没有办法直接获取的。 于是，我写了一个小工具

对于 fentry 程序而言，在 arm64 上做 backtrace 不像 x86 上那么简单；第一步找到可用的 frame pointer 就很费劲了。 毕竟，找到 frame pointer 之后，就可以通过 frame pointer 逐级回溯，找到调用者的 IP 和 FP

对于 socket 编程，在用户态看到的只能是 fd；而在内核态，大部分时候看到的是 sock。 fd 和 sock 之间的关系，是在内核态的 syscall 里建立的；所以，在 connect 和 accept 等 syscall 里

tailcall 是 v4.2 内核便已引入的一个特性，它允许一个 BPF 程序调用另一个程序，而无需返回原程序。 bpf: allow bpf programs to tail-call other bpf programs 然而，在 BPF 子系统不断地引入新特性的同时，t

最近，在上线 XDP 网关新版本的时候，触发了 v5.15 内核的一个 tailcall BUG，导致了一个很奇怪的问题：在一个 XDP 程序的 subprog 里，调用了 bpf_tail_call()

使用 bpf 跟踪 bpf map 的更新、删除函数，以此确认是谁动了 bpf map。 TL;DR 已实现对 bpf map 的更新、删除函数的跟踪，未实现批量操作 bpf map 函数的跟踪；源代码：git

在 eBPF Talk: 自制查看 bpf prog 反汇编的工具 里提到的 bpftool BUG Wrong callq address displayed，花了两三天时间将它给修了。 TL;DR [PATCH bpf v3] bpf, bpftool: Fix incorrect disasm pc 已合入 bpf 仓库。 BUG 复现 使用 bpftool

目前，我知道的查看 bpf prog 反汇编的办法有： 使用 bpftool prog dump jited； 使用 gdb -q -c /proc/kcore -ex 'disas/r 0xffffffffc00a6188,+0x143' -ex 'quit'； 使用 drgn contrib/bpf_inspec.p