Cilium/pwru项目中BPF全局变量使用不当导致的内存竞争问题分析

在Cilium项目的pwru（Packet Where are you）工具中，开发人员发现了一个关于BPF全局变量使用不当导致的内存竞争问题。本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题背景

pwru是一个基于eBPF技术的内核网络数据包追踪工具，它能够帮助开发者快速定位网络数据包在内核中的处理路径。在实现过程中，pwru需要输出sk_buff（套接字缓冲区）和skb_shared_info（共享信息结构）的详细信息。

问题分析

在原始实现中，开发者使用了静态全局变量来存储临时数据：

static struct btf_ptr p = {};
static struct print_skb_value v = {};

这些变量被放置在.bss段中，在BPF程序中表现为全局变量。然而，这种实现方式存在严重问题：

1. 内存竞争风险：当多个CPU核心同时执行BPF程序时，这些全局变量会被共享访问，缺乏必要的同步保护机制
2. 数据一致性破坏：一个CPU核心正在写入的数据可能被另一个CPU核心的写入操作覆盖
3. 输出结果不可靠：最终输出的数据可能混合了不同CPU核心处理的不同数据包信息

技术细节

在Linux内核中，BPF程序有以下特点：

1. BPF程序可能在多个CPU核心上并发执行
2. 传统的全局变量在BPF中实际上是共享的
3. BPF缺乏传统的内存锁机制来保护共享数据

pwru工具中用于输出skb和shinfo的函数set_skb_btf和set_shinfo_btf都使用了这种不安全的全局变量模式，这会导致：

• 当多个数据包在不同CPU上同时处理时
• 它们的输出信息会互相干扰
• 最终可能导致输出错误或丢失部分数据

解决方案

正确的做法是使用BPF的per-CPU数组映射来替代全局变量：

1. 每个CPU核心都有自己独立的存储空间
2. 消除了CPU间的数据竞争
3. 保证了输出数据的完整性和正确性

实现上需要：

1. 定义per-CPU数组映射
2. 通过bpf_get_smp_processor_id()获取当前CPU ID
3. 使用CPU ID作为索引访问对应的存储位置

这种模式是BPF程序中处理并发数据的标准做法，能够有效避免多核环境下的数据竞争问题。

总结

在BPF程序开发中，开发者必须特别注意并发安全问题。全局变量的使用需要格外谨慎，在多数情况下应该使用per-CPU的数据结构来替代。pwru工具的这个案例很好地展示了在多核环境下不正确使用全局变量可能导致的问题，以及正确的解决方案。

对于BPF开发者来说，理解这些并发编程的注意事项至关重要，特别是在开发网络诊断工具这类可能被频繁调用的BPF程序时。正确的并发处理不仅能保证程序的正确性，也能提高整体性能。