ebpf-for-windows项目中km_mt_stress_tests测试失败的技术分析

在ebpf-for-windows项目中，km_mt_stress_tests测试用例持续出现失败现象，这是一个涉及内核模式多线程压力测试的关键测试场景。本文将深入分析该测试失败的根本原因、技术背景以及解决方案。

测试场景概述

km_mt_stress_tests测试主要验证eBPF程序在多线程环境下的稳定性和正确性。测试场景模拟了两个线程同时加载和附加eBPF程序的情况：

• 一个线程加载并附加IPv4连接跟踪程序
• 另一个线程加载并附加IPv6连接跟踪程序

测试的核心目的是验证在多线程并发环境下，eBPF程序的加载、附加和卸载操作能够正确执行，不会出现资源竞争或状态不一致的问题。

失败现象分析

测试失败时，日志显示以下关键错误信息：

_load_attach_program(0) FATAL ERROR: bpf_prog_attach(cgroup_count_connect4.sys) failed. program:count_tcp_connect4, errno:22

进一步分析日志发现，错误发生在Windows过滤平台(WFP)的事务处理过程中：

FwpmTransactionBegin failed with status 0xC022000E (The call is not allowed from within an explicit transaction)

这表明在尝试开始一个新的WFP事务时，系统检测到已经存在一个显式事务正在进行中，导致操作被拒绝。

根本原因

经过代码审查和技术分析，发现问题出在WFP过滤器处理的多线程同步机制上：

1. 全局过滤器引擎句柄：当前实现使用一个全局的过滤器引擎句柄，多个线程通过这个共享句柄调用FwpmTransactionBegin。

2. 事务冲突：当两个线程同时尝试附加eBPF程序时，它们都会调用net_ebpf_extension_add_wfp_filters函数，该函数内部会启动WFP事务。由于使用同一个引擎句柄，第二个线程的调用会失败。

3. 错误传播：WFP事务失败导致整个eBPF程序附加操作失败，最终表现为测试用例不通过。

技术背景

Windows过滤平台(WFP)是Windows操作系统提供的一套网络数据包过滤框架，它具有以下特点：

• 事务性操作：许多WFP操作需要在事务中执行以保证原子性
• 句柄关联：每个引擎句柄维护独立的事务状态
• 线程安全：单个句柄不支持并发事务操作

在eBPF的实现中，网络相关的eBPF程序(如connect4/connect6)需要通过WFP来拦截和处理网络事件，这就引入了对WFP的依赖。

解决方案

针对这个问题，可以考虑以下几种解决方案：

1. 同步机制：在访问WFP引擎句柄时添加互斥锁，确保同一时间只有一个线程能执行事务操作。

2. 独立句柄：为每个线程或每个操作创建独立的WFP引擎句柄，避免共享状态。

3. 重试机制：在检测到事务冲突时自动重试操作。

考虑到当前代码正在经历重构(PR 3751)，最佳实践是等待重构完成后，在新的架构基础上实现上述解决方案之一。特别是重构后的代码可能会提供更好的隔离性和更清晰的资源管理方式。

影响范围

这个问题不仅影响测试用例，在实际生产环境中也可能导致以下问题：

• 在多线程环境下加载多个eBPF程序时失败
• 并发网络策略更新时出现不可预测的行为
• 系统性能下降（如果使用简单的全局锁方案）

总结

km_mt_stress_tests测试失败揭示了ebpf-for-windows项目中一个重要的多线程同步问题。通过深入分析WFP的事务机制和eBPF程序的加载流程，我们确定了全局过滤器引擎句柄共享是问题的根源。解决这个问题不仅能使测试通过，更能提高整个项目在多线程环境下的稳定性和可靠性。

对于开发者而言，这个案例也提醒我们在设计系统时需要特别注意：

• 共享资源在多线程环境下的访问控制
• 外部系统(如WFP)的线程安全假设
• 压力测试在验证系统稳定性中的重要性

后续的修复工作将基于PR 3751的进展，采用适当的同步机制或资源隔离方案来解决这个问题。