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

在修复一个由 freplace 引起的 tailcall 无限循环的问题时，接纳社区的建议：禁止将 freplace prog 更新到 prog_array map 中。 使用场景 在项目中，freplace prog 当作 tail-callee 的用法如下： 在 dispatcher prog

守护 spinlock。 eBPF Talk: spinlock 详解 当使用 spinlock 进行统计时 eBPF Talk: 正确地进行统计，必须要使用 bpf_spin_lock() 和 bpf_spin_unlock() 来保护 spinlock 变量： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 struct xdp_stat_item {

在 eBPF Talk: XDP 解析所有 TCP options 里，已经做到了使用 XDP 解析所有 TCP options 的功能。 不过，其中使用了 percpu map 在 XDP 和 freplace 之间传递 offset；那么，是否有办法将该 percpu map 优化掉

在 eBPF Talk: 耗时 10 个月，修复了又一个 tailcall 的 bug 之后，再下一城，再次修复与 tailcall 有关的一个 BUG： bpf: Fix updating attached freplace prog to prog_array map BUG 危害 这个 BUG 会导致内核 panic： 1 2 3

最近在使用 ringbuf 的 bpf_ringbuf_reserve() 时踩了一个坑，记录一下。 ringbuf 简介 ringbuf 是 BPF 中能够取代 PERF_EVENT_ARRAY 的特殊 map 类型，提供了类似的 helpers: bpf_ringbuf_output(): 将数据写入 ringbuf。 bpf_ringbuf_reserve(): 为数据预留空间。 bpf_ringbuf_submit():

优化的地方如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 5159c7a229229..7c130001fbfe7 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1234,13 +1234,11 @@ bool ex_handler_bpf(const struct exception_table_entry *x, struct pt_regs

使用 fentry 能解析到 TOA option，eBPF Talk: BPF 读取 TOA 的 4 种方式。 上难度，如何使用 XDP 解析所有的 TCP options 呢？ 太长不读：使用 freplace 解析 TCP option，使用 XDP 遍