编程面试：如何用 eBPF CO-RE 编写可移植的内核追踪程序？
题干与适用场景
观测代理需要在多种发行版和内核版本上统计系统调用延迟。手工为每个内核编译会造成发布矩阵爆炸，直接读取内核结构偏移又容易失效。请解释 BTF、CO-RE 重定位和 libbpf 的职责，并设计一条可验证的构建、加载、事件读取和兼容路径。
面试官考察点
- 是否理解 BTF 类型信息、编译器生成的重定位记录和加载期修补的关系。
- 能否区分 CO-RE 解决的结构布局差异与 verifier、helper、程序类型限制。
- 能否设计 ring buffer 或 perf buffer 的事件生命周期、丢失统计和用户态解码。
- 能否处理缺少 BTF、字段不存在、内核能力不足和程序加载失败。
回答前需要澄清的问题
- 目标内核是否启用 BTF，发行版是否提供
/sys/kernel/btf/vmlinux？ - 追踪点、kprobe、fentry 或 LSM 哪种程序类型可用，权限和特权边界是什么？
- 事件量、延迟预算、允许的丢失率和用户态消费模型是什么？
- 需要支持哪些架构、内核版本和容器部署方式？
- 没有目标字段或 verifier 拒绝时，代理应关闭该指标还是使用替代探针？
30 秒回答框架
我会用 clang 生成带 BTF 和 CO-RE 重定位信息的单一 BPF 对象，由 libbpf 在目标机加载时根据运行内核的 BTF 修补字段偏移。用户态通过生成的 skeleton 管理 map、程序和 ring buffer，并校验能力、BTF 与程序类型。字段缺失或加载失败时记录原因，停用该指标或切换到稳定 tracepoint，不返回伪造数据。基准覆盖多内核、并发事件、丢失与卸载恢复。
分步骤深入解答
第一步：划分编译期和加载期职责
编译器把 BPF 程序、类型信息和 CO-RE relocation 写入对象文件。加载时 libbpf 使用目标内核 BTF 找到结构、字段和偏移，更新指令中的立即数或偏移。CO-RE 因此减少了按内核构建的需要，但不会让任意 helper、kfunc 或程序类型自动可用。
第二步：选择稳定的探针边界
优先使用稳定 tracepoint 或 fentry，并确认目标内核暴露的事件字段；kprobe 可覆盖更多路径，却更依赖符号和参数布局。对每个字段用 CO-RE 访问宏表达意图，避免手写固定偏移。程序应只读取必要字段，缩小 verifier 分析和事件大小。
第三步：设计事件结构与传输
在 BPF 侧记录 pid、时间戳、系统调用标识和必要的延迟数据，使用 ring buffer 或 perf buffer 发送到用户态。事件结构保持固定大小或显式版本字段，用户态检查长度和版本。每个 CPU、进程和队列都应有丢失计数，不能把缓冲区溢出静默当成零延迟。
第四步：让 verifier 约束成为设计输入
边界检查、循环上界、指针类型和 helper 返回值必须满足 verifier。把复杂解析移到用户态，避免在 BPF 中做不可证明的遍历。加载前编译器和 skeleton 生成的 map 定义要与程序访问一致；日志应保留 verifier 失败的摘要和内核版本，便于定位。
第五步：处理 BTF 与字段差异
加载前检查目标 BTF 是否可读，并用 CO-RE 可选字段或 feature probe 判断字段存在。若结构变更使重定位失败，关闭该指标或选择兼容 tracepoint；不能把无法读取的字段填成默认值后继续报告精确延迟。架构差异也要在 CI 的多内核矩阵中验证。
第六步：设计构建与发布链路
固定 clang、libbpf 和 skeleton 生成版本，产出带 BTF 的对象并记录 build ID。发布包包含用户态 loader、BPF 对象和最小能力清单；启动时先自检，再加载。容器环境要明确所需的 BPF 文件系统、权限和内核配置，失败时给出可行动的原因。
第七步：验证性能、正确性与回滚
在不同发行版、架构和内核上比较字段值、事件计数与独立工具结果。压测高事件率下的 CPU、内存、ring buffer 丢失、用户态落后和 tail latency。升级时保留旧对象或稳定探针作为回滚路径，卸载时确认 link、map 和线程都已释放。
高质量示范回答
我会用 clang 生成包含 BTF 与 CO-RE relocation 的单一对象，由 libbpf 在目标机依据运行内核 BTF 修补字段偏移。探针优先选择稳定 tracepoint 或 fentry，BPF 只记录固定版本的最小事件，用户态 skeleton 通过 ring buffer 解码并统计丢失。启动前检查 BTF、程序类型、helper 能力和字段存在性；重定位或 verifier 失败就停用该指标或切换稳定探针，绝不填充伪造数据。CI 覆盖多架构、多内核、高事件率和卸载恢复，发布包保留旧探针用于回滚。
常见错误
- 把 CO-RE 当成对所有 helper、kfunc 和 verifier 限制的兼容层。
- 手写结构偏移，绕过 BTF 和重定位，导致升级后读取错误字段。
- 事件结构没有版本和长度检查，用户态把截断数据当成有效样本。
- 缓冲区丢失不计数，最终把观测缺口报告成零延迟。
- 缺少 BTF 或字段时填默认值继续上报，隐藏了兼容性失败。
追问及应对
追问一：CO-RE 重定位发生在什么时候？
编译阶段把 relocation 写入 BPF 对象，加载阶段 libbpf 使用目标内核 BTF 解析并修补指令中的字段信息。它不是运行时每个事件都重新计算偏移。
追问二：没有 vmlinux BTF 能运行吗？
取决于程序和发行版提供的 BTF、探针类型及 libbpf 能力。应在启动自检中确认可用信息；无法安全解析时停用该程序或改用不依赖该字段的稳定探针。
追问三：为什么不用 kprobe 覆盖所有版本？
kprobe 灵活但更依赖符号、参数和内联行为，升级后的语义稳定性较弱。稳定 tracepoint 或 fentry 可降低维护成本，仍需验证目标内核是否提供。
追问四：如何证明没有漏报？
同时统计 BPF 事件数、ring buffer 丢失数、用户态消费数和独立系统调用计数，按 CPU 与时间窗口对账。任何不一致都应暴露为缺失或降级状态，而非默认为零。
追问五：verifier 拒绝如何排查？
保存加载日志、内核版本、目标架构、BTF ID 和 verifier 摘要，先缩小到指针边界、循环上界、helper 或 map 定义差异，再用最小复现程序验证。修复后重新跑多内核矩阵。