树莓派Debian 5.15内核eBPF全局变量支持问题求助

错误原因分析 #

你之前的思路存在两个核心问题：

• 跨kprobe无法共享局部/堆内存：foo1和foo2是两个独立的eBPF程序，各自运行在独立的内核上下文，foo1中用kzalloc分配的堆内存指针p，在foo2中根本无法访问，这种写法本身就不符合eBPF的运行逻辑。
• 全局变量使用方式错误：虽然Linux 5.2+支持eBPF全局变量，但全局变量只能存储固定大小的静态数据，不能用来保存动态分配的内存指针——eBPF验证器会直接阻止这种可能引发内存泄漏、野指针的操作。你看到的“未知操作码”错误，就是因为编译器生成了eBPF验证器不认可的内存访问指令（比如引用未正确标记的全局/静态变量）。

正确解决方案：用eBPF哈希表存储数据包记录 #

要实现跨kprobe的数据包信息共享，必须使用eBPF Map（这里推荐哈希表类型BPF_MAP_TYPE_HASH），它是eBPF程序之间、eBPF与用户空间之间共享数据的标准方式。

步骤1：定义哈希表与数据结构 #

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

// 存储数据包到达时间戳的结构体
struct packet_record {
    __u64 ts_arrival;  // 纳秒级时间戳
};

// 定义哈希表：键为数据包唯一标识（这里用TCP校验和，建议用IP+端口+校验和组合避免冲突），值为时间戳记录
struct bpf_map_def SEC("maps") packet_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(__u32),  // 假设用32位TCP校验和作为键
    .value_size = sizeof(struct packet_record),
    .max_entries = 1024,  // 根据并发数据包数调整，避免溢出
};

步骤2：入接口kprobe（foo1）逻辑 #

在数据包到达wlan0时，将唯一标识和到达时间戳存入哈希表：

SEC("kprobe/foo1")
int kprobe_foo1(struct pt_regs *ctx) {
    __u32 tcp_csum = ...;  // 从数据包中提取TCP校验和
    __u64 ts_arr = bpf_ktime_get_ns();  // 获取到达时间戳

    struct packet_record rec = {.ts_arrival = ts_arr};
    // 将记录存入哈希表，存在则覆盖，不存在则新增
    bpf_map_update_elem(&packet_map, &tcp_csum, &rec, BPF_ANY);

    return 0;
}

步骤3：出接口kprobe（foo2）逻辑 #

在数据包从eth0离开时，查询哈希表获取到达时间戳，计算时延并清理记录：

SEC("kprobe/foo2")
int kprobe_foo2(struct pt_regs *ctx) {
    __u32 tcp_csum = ...;  // 提取同一数据包的TCP校验和
    __u64 ts_dep = bpf_ktime_get_ns();  // 获取离开时间戳

    // 查询哈希表中的到达时间戳记录
    struct packet_record *rec = bpf_map_lookup_elem(&packet_map, &tcp_csum);
    if (rec) {
        __u64 delay_ns = ts_dep - rec->ts_arrival;
        // 可选：将时延结果输出到用户空间（比如用perf event或另一个map）
        // ...

        // 从哈希表中删除记录，避免内存泄漏
        bpf_map_delete_elem(&packet_map, &tcp_csum);
    }

    return 0;
}

关键注意事项 #

• 避免键冲突：仅用TCP校验和作为键可能存在冲突，建议用struct { __u32 src_ip; __u32 dst_ip; __u16 src_port; __u16 dst_port; __u32 csum; }作为哈希表的键，确保每个数据包的唯一性。
• 哈希表大小调整：max_entries要根据你系统的并发转发数据包数设置，太小会导致新记录无法存入。
• 工具链版本：确保你使用的clang/llvm版本支持eBPF编译（建议用LLVM 10+版本），避免因工具链过老生成不兼容的指令。

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