需求来了：需要在 XDP 里拦截已经建立的 tcp 连接，不是 DROP，而是要回 rst 包。 快速搜索一下，居然没有使用 XDP 来 reset tcp 连接的例子，只好亲自解决了。 解决办法

分享两条 bpfsnoop（emm 从 btrace 改名而来）使用 tp_btf 支持动态追踪 tracepoint 的经验。 如何确定 tracepoint 对应的参数？ 如何绕过 verifier 校验 tp_btf prog 的 BUG？ bpfsnoop 里的解法请参考

凑个热闹，静态地对比一下 tracepoint、raw_tp/tp_btf、kprobe 和 fentry/fexit 四种 bpf 动态追踪技术的运行时性能。 eBPF代码性能调

btrace 是什么？btrace 是一款 bpf 时代的现代化内核函数动态追踪工具。 btrace 重命名自 bpflbr，参考 eBPF Talk: 使用 Last Branch Record 动态追踪内核函数，在 bpflbr v0.1.0 的基础上，

Last Branch Record，简称 LBR，是 CPU 提供的一种硬件功能，可以记录程序执行过程中的分支跳转信息；目前，Intel CPU、AMD CPU 均已支持 LBR 功能；

在使用 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 里