net-next内核未显式加载eBPF却出现默认程序问题咨询

我之前也碰到过一模一样的情况，在net-next这种前沿内核分支里，出现未手动加载却能被bpftool检测到的eBPF程序，大概率是正常现象，不是你操作出了问题。下面给你拆解可能的原因和排查思路：

• 内核内置的默认eBPF程序：net-next作为内核的前沿开发分支，会提前引入很多新特性，其中就包含部分默认启用的eBPF程序——这些程序是内核初始化时自动部署的，用来做自身功能优化或新特性测试。比如某些网络子系统、安全模块会依赖轻量eBPF程序实现特定逻辑，而你开启的CONFIG_BPF_JIT_ALWAYS_ON会让这些程序被JIT编译，更容易被bpftool捕捉到。

• 系统组件隐式加载：有些系统服务或工具（比如systemd的新模块、现代网络管理工具）在net-next内核环境下，会自动适配新特性，悄悄加载eBPF程序，哪怕你没手动执行加载命令。比如最新的网络QoS管控、进程安全监控组件，都可能默认启用eBPF机制。

• 排查两个系统差异的具体步骤：

  1. 先执行bpftool prog list和bpftool map list，详细列出所有eBPF程序和映射，重点看它们的类型、附加点（attach point）和UID——如果UID是0，大概率是内核加载的；非0则可能是用户空间组件触发的。
  2. 对比两个系统的内核配置：可以通过zcat /proc/config.gz导出配置，重点检查除了CONFIG_BPF_JIT_ALWAYS_ON之外的BPF相关选项，比如CONFIG_BPF_LSM、CONFIG_BPF_STREAM_PARSER、CONFIG_BPF_PRELOAD等，这些选项都可能触发默认程序加载。
  3. 查看内核启动日志：用dmesg | grep -i bpf或journalctl -k | grep -i bpf搜索相关记录，内核加载eBPF程序时一般会打印日志，能直接看到程序的来源和用途。
  4. 对比系统服务状态：用systemctl list-units --type=service列出两个系统的服务，重点排查网络、安全类服务的差异——比如某台系统启用了systemd-networkd的eBPF优化，另一台没开，就会出现这种差异。

如果最后确认是内核内置的默认程序，这属于net-next分支的正常开发行为，这类程序一般是为了测试新特性或优化内核逻辑，后续稳定版内核会根据需求决定是否保留默认加载。要是你不需要这些程序，可以尝试关闭对应的内核配置选项，但注意这可能影响部分内核功能的正常运行。

内容的提问来源于stack exchange，提问作者Mark