feat(starry-kernel): add LKM support via kmod-loader integration

[CN-TangLin]

概述

为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate，实现 init_module / delete_module / finit_module 系统调用。

背景

可加载内核模块是 Linux 内核动态扩展的标准机制。本实现允许在运行时加载/卸载内核模块，模块可以使用 kprobe、eBPF 等内核服务，为 StarryOS 提供动态扩展能力。前置依赖 #847（kprobe）和 #848（eBPF）均已合并到 dev。

变更内容

新增文件

• kmod_loader.rs：LKM 加载器核心实现
  • ELF 加载与重定位
  • resolve_symbol：内核符号解析（依赖 kallsyms）
  • 模块 init/cleanup 生命周期管理
• test-kmod-loader/：LKM 用户态测试程序（CMake + C）

修改文件

• lib.rs：注册 kmod_loader 模块
• syscall/mod.rs：添加 init_module、delete_module、finit_module 系统调用
• Cargo.toml：添加 kmod-loader = "0.2" 依赖

验证

• cargo fmt --check：通过
• cargo xtask clippy --package starry-kernel：通过（单独 feature 配置均通过）
• test-kmod-loader 用户态测试通过

关联

• 前置依赖：feat(starry-kernel): add kprobe support #847（kprobe）✅ 已合并、feat(starry-kernel): add eBPF subsystem (maps, VM, helpers, perf events) #848（eBPF）✅ 已合并
• resolve_symbol 完整功能依赖 Adds support for kernel symbol dumping via kallsyms #837（kallsyms）合并
• 下游依赖：无

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate，实现 init_module / delete_module / finit_module 系统调用。新增 kmod_loader.rs（~180 行）包含页对齐内存分配、ELF section 权限映射和系统调用入口。同时基于 feat/starry-ebpf 分支，包含 ebpf.rs、kprobe.rs、perf_event.rs 等前置代码。附带 7 个错误路径 C 测试用例。

实现逻辑

• KmodSectionMem 通过 alloc 实现页对齐内存分配，change_perms 通过修改页表实现 R/W/X 权限切换，设计合理。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数，之后 forget 使模块常驻内存。符合当前无卸载实现的设计。
• sys_delete_module / sys_finit_module 为桩实现，返回 Unsupported，待后续完善。
• 系统调用路由在 syscall/mod.rs 中正确注册，同时将 bpf 和 perf_event_open 从 dummy_fd 移至实际处理。

验证结果

• ✅ cargo fmt --check 通过
• ⚠️ cargo clippy --manifest-path os/StarryOS/kernel/Cargo.toml --all-features 编译失败，错误来自 ax-hal/kcov.rs:82（__PERCPU_IN_KCOV_TRACE 未定义），属于基础分支的已有问题，非本 PR 引入。
• ⚠️ CI 状态：mergeable_state=unstable，无法确认是否有 CI 流水线在运行。

阻断性问题

1. 测试安装路径错误：test-kmod-loader/c/CMakeLists.txt 将二进制安装到 usr/bin，而 syscall 测试组的 test_commands（qemu-*.toml）遍历 /usr/bin/starry-test-suit/*。同目录下所有其他测试（如 test-kill-tgkill、test-close、test-write 等）均安装到 usr/bin/starry-test-suit。此测试将不会被测试运行器发现和执行。

2. KmodSectionMem null 指针 Drop 未定义行为：当 vmalloc 分配失败时，StarryKmodHelper::vmalloc 创建一个 ptr 为 null_mut() 的 KmodSectionMem，但其 Drop 实现调用 dealloc(self.ptr, self.layout)。Rust 要求 dealloc 的指针必须是由同一分配器以相同 layout 分配的非空指针，对 null 指针调用 dealloc 是未定义行为，可能导致内核崩溃。应改为返回 Err 或使用 Option 表示分配失败。

建议性意见

3. core::mem::forget(owner)（第 155 行）使模块资源常驻内存，这是当前无卸载功能下的合理选择，但建议添加注释说明 forget 的意图和未来 delete_module 实现时的释放计划。

4. flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），PR 实现正确，可考虑向上游提 issue 修正。

未解决的审查会话

无历史审查会话。

结论

需要修复上述两个阻断性问题后方可合并。

Powered by mimo-v2.5-pro

[mai-team-app]

🐛 阻断：安装路径错误

此处安装目标为 usr/bin，但 qemu-smp1/syscall/qemu-x86_64.toml 的 test_commands 遍历 /usr/bin/starry-test-suit/*。同目录下所有其他测试均安装到 usr/bin/starry-test-suit。

修复方式：

install(TARGETS test-kmod-loader RUNTIME DESTINATION usr/bin/starry-test-suit)

当前路径下测试不会被分组测试运行器发现，等于没有 CI 覆盖。

[mai-team-app]

🐛 阻断：null 指针调用 dealloc 是未定义行为

此处 Drop 对 self.ptr 调用 dealloc。当上方 vmalloc 分配失败时（第 93-97 行），会创建 ptr: null_mut() 的实例。Rust 的 dealloc 要求指针必须是由同一 layout 从分配器获取的非空指针，对 null 指针调用是 UB。

建议修复方式：

• 将 vmalloc 的失败情况改为返回 Err，或使用 Option<Box<dyn SectionMemOps>>
• 或在 Drop 中添加 null 检查：if !self.ptr.is_null() { unsafe { dealloc(self.ptr, self.layout) }; }

后者虽然简单但更安全，且应同时在 as_ptr/as_mut_ptr/change_perms 中处理 null 情况。

[mai-team-app]

此处创建的 null 指针 KmodSectionMem 在 drop 时会导致 UB（见上方 Drop 注释）。建议改为：

None => {
    warn!("kmod: vmalloc failed for size {size}");
    // 返回一个安全的空操作实现，或让调用方处理错误
    alloc::boxed::Box::new(NullSectionMem) // 实现 no-op 的 SectionMemOps
}

或者直接让 KernelModuleHelper::vmalloc 返回 Result 而非 panicking。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。基于 feat/starry-ebpf 分支，同时包含 ebpf.rs、kprobe.rs、perf_event.rs 等前置代码。附带 7 个错误路径 C 测试用例。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计思路合理。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported。
• 系统调用路由在 syscall/mod.rs 中正确注册，同时将 bpf 和 perf_event_open 从 dummy_fd 移至实际处理。

CI 状态

所有 CI 检查均为 skipped 状态，mergeable_state=blocked。CI 跳过是因为 PR 基于 feat/starry-ebpf 分支，可能不满足 CI 触发条件。无法从 CI 获取验证信息。

前次审查意见

前一次审查（mai-team-app[bot]，CHANGES_REQUESTED）指出了相同的两个阻断性问题，当前 PR head 未修复。

阻断性问题

1. 测试安装路径错误：test-kmod-loader/c/CMakeLists.txt 将二进制安装到 usr/bin，但 syscall 测试组的 qemu-x86_64.toml 的 test_commands 遍历 /usr/bin/starry-test-suit/*。同目录下所有其他测试（包括 test-ebpf-basics）均安装到 usr/bin/starry-test-suit。此测试不会被分组测试运行器发现和执行，等于没有 CI 覆盖。

2. KmodSectionMem null 指针 Drop 未定义行为：当 vmalloc 分配失败时，StarryKmodHelper::vmalloc 创建一个 ptr 为 null_mut() 且 layout 为 (1,1) 的 KmodSectionMem，但其 Drop 实现对 self.ptr 调用 dealloc(self.ptr, self.layout)。Rust 要求 dealloc 的指针必须是由同一 layout 从分配器获取的非空指针，对 null 指针调用 dealloc 是未定义行为，可能导致内核崩溃。建议在 Drop 中添加 null 检查，或让 vmalloc 在失败时返回一个安全的 no-op 实现。

建议性意见

3. core::mem::forget(owner) 使模块资源常驻内存，是当前无卸载功能下的合理选择，但建议添加注释说明 forget 的意图和未来 delete_module 实现时的释放计划。
4. flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），PR 实现正确，可考虑向上游提 issue 修正。

结论

需要修复上述两个阻断性问题后方可合并。

Powered by mimo-v2.5-pro

[mai-team-app]

🐛 阻断：安装路径错误

此处安装目标为 usr/bin，但 qemu-smp1/syscall/qemu-x86_64.toml 的 test_commands 遍历 /usr/bin/starry-test-suit/*。同目录下所有其他测试（包括 test-ebpf-basics）均安装到 usr/bin/starry-test-suit。

修复方式：

install(TARGETS test-kmod-loader RUNTIME DESTINATION usr/bin/starry-test-suit)

当前路径下测试不会被分组测试运行器发现，等于没有 CI 覆盖。此问题已在前次审查中指出，仍未修复。

[mai-team-app]

🐛 阻断：null 指针调用 dealloc 是未定义行为

Drop 实现对 self.ptr 调用 dealloc。当上方 vmalloc 分配失败时（第 93-97 行），会创建 ptr: null_mut() 且 layout 为 Layout::from_size_align(1, 1) 的实例。Rust 的 dealloc 要求指针必须是由同一 layout 从分配器获取的非空指针，对 null 指针调用是 UB，可能导致内核崩溃。

建议修复方式：在 Drop 中添加 null 检查：

impl Drop for KmodSectionMem {
    fn drop(&mut self) {
        if !self.ptr.is_null() {
            unsafe { dealloc(self.ptr, self.layout) };
        }
    }
}

同时建议让 as_ptr/as_mut_ptr/change_perms 也正确处理 null 情况。

此问题已在前次审查中指出，仍未修复。

[mai-team-app]

⚠️ 建议：此处创建的 null 指针 KmodSectionMem 在 drop 时会导致 UB（见上方 Drop 注释）。更好的做法是让 KernelModuleHelper::vmalloc 返回 Result 类型，或在此处返回一个安全的 no-op 实现（如只读的零大小 SectionMemOps），而非创建 null 指针实例。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。基于 feat/starry-ebpf 分支，同时包含 ebpf.rs、kprobe.rs、perf_event.rs 等前置代码。附带 7 个错误路径 C 测试用例。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计思路合理。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported。
• 系统调用路由在 syscall/mod.rs 中正确注册，同时将 bpf 和 perf_event_open 从 dummy_fd 移至实际处理。

CI 状态

所有 CI 检查均为 skipped 状态，mergeable_state=dirty。CI 跳过是因为 PR 基于 feat/starry-ebpf 分支，可能不满足 CI 触发条件。无法从 CI 获取验证信息。

重复/重叠分析

• base 分支：origin/dev 上不存在任何 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，本 PR 依赖其分支，属于前置依赖，非重复。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了对此 PR 的依赖，属于互补关系。
• 结论：本 PR 无重复实现，与相关 PR 关系明确（前置依赖 + 未来互补）。

前次审查意见

本 PR 已收到两次 mai-team-app[bot] 的 CHANGES_REQUESTED 审查（#4338145783、#4338163988），均指出相同的两个阻断性问题。当前 PR head（003b18d3）未做任何修复提交。

阻断性问题

1. 🐛 测试安装路径错误：test-kmod-loader/c/CMakeLists.txt 将二进制安装到 usr/bin，但 syscall 测试组的所有其他测试均安装到 usr/bin/starry-test-suit。测试运行器遍历 /usr/bin/starry-test-suit/*，此测试不会被测试运行器发现和执行，等于没有 CI 覆盖。此问题已在两次前次审查中指出，仍未修复。

2. 🐛 KmodSectionMem null 指针 Drop 未定义行为：当 vmalloc 分配失败时，StarryKmodHelper::vmalloc 创建一个 ptr 为 null_mut() 且 layout 为 (1,1) 的 KmodSectionMem，但其 Drop 实现对 self.ptr 调用 dealloc(self.ptr, self.layout)。Rust 要求 dealloc 的指针必须是由同一分配器以相同 layout 分配的非空指针，对 null 指针调用 dealloc 是未定义行为，可能导致内核崩溃。此问题已在两次前次审查中指出，仍未修复。

建议性意见

3. core::mem::forget(owner) 使模块资源常驻内存，是当前无卸载功能下的合理选择，但建议添加注释说明 forget 的意图和未来 delete_module 实现时的释放计划。
4. flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），PR 实现正确，可考虑向上游提 issue 修正。

结论

需要修复上述两个阻断性问题（测试安装路径和 null 指针 Drop UB）后方可合并。这两个问题已在之前两次审查中明确指出，请优先处理。

Powered by glm-5.1

[mai-team-app]

🐛 阻断：安装路径错误

此处安装目标为 usr/bin，但 qemu-smp1/syscall 目录下所有其他测试均安装到 usr/bin/starry-test-suit。测试运行器遍历 /usr/bin/starry-test-suit/*，此测试不会被分组测试运行器发现和执行，等于没有 CI 覆盖。

此问题已在之前两次审查中指出，仍未修复。

修复方式：

install(TARGETS test-kmod-loader RUNTIME DESTINATION usr/bin/starry-test-suit)

[mai-team-app]

🐛 阻断：null 指针调用 dealloc 是未定义行为

Drop 实现对 self.ptr 调用 dealloc。当上方 vmalloc 分配失败时（第 93-97 行），会创建 ptr: null_mut() 且 layout 为 Layout::from_size_align(1, 1) 的实例。Rust 的 dealloc 要求指针必须是由同一 layout 从分配器获取的非空指针，对 null 指针调用是 UB，可能导致内核崩溃。

此问题已在之前两次审查中指出，仍未修复。

建议修复方式：

impl Drop for KmodSectionMem {
    fn drop(&mut self) {
        if !self.ptr.is_null() {
            unsafe { dealloc(self.ptr, self.layout) };
        }
    }
}

同时建议让 as_ptr/as_mut_ptr/change_perms 也正确处理 null 情况。

[mai-team-app]

⚠️ 建议：此处创建的 null 指针 KmodSectionMem 在 drop 时会导致 UB（见上方 Drop 注释）。更优方案是让 KernelModuleHelper::vmalloc 返回 Result 类型，或在此处返回一个安全的 no-op 实现（如零大小 SectionMemOps），而非创建 null 指针实例。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。新增 kmod_loader.rs（~194 行）包含页对齐内存分配、ELF section 权限映射、NullSectionMem 安全回退和系统调用入口。同时基于 feat/starry-ebpf 分支，包含 ebpf.rs、kprobe.rs、perf_event.rs 等前置代码。附带 7 个错误路径 C 测试用例。

前次审查问题修复状态

本 PR 已收到 3 次 mai-team-app[bot] 的 CHANGES_REQUESTED 审查，均指出两个阻断性问题。最新提交 6ec4920d7 已修复全部问题：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，测试运行器（遍历 /usr/bin/starry-test-suit/*）现在可以发现并执行 test-kmod-loader。

2. ✅ KmodSectionMem null 指针 Drop UB：Drop 实现已添加 if !self.ptr.is_null() 检查。同时 vmalloc 失败时不再创建 null 指针实例，而是返回安全的 NullSectionMem（实现 SectionMemOps trait，返回 null 指针和 false），完全消除了 UB 风险。

3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来 delete_module 实现时的释放计划。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计思路合理。
• NullSectionMem 作为 vmalloc 失败时的安全回退实现，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported，待后续完善。
• 系统调用路由在 syscall/mod.rs 中正确注册，同时将 bpf 和 perf_event_open 从 dummy_fd 移至实际处理。
• flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），本 PR 实现正确，aarch64 条件编译和通用 flush_icache_all 处理得当。

重复/重叠分析

• base 分支：origin/dev 上不存在任何 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，本 PR 依赖其分支，属于前置依赖，非重复。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了对此 PR 的依赖，属于互补关系。
• 结论：本 PR 无重复实现，与相关 PR 关系明确（前置依赖 + 未来互补）。

已知限制

• resolve_symbol 当前为桩实现返回 None，待 PR #837（kallsyms）合并后可通过 feature gate 启用完整符号解析。
• delete_module 和 finit_module 为 stub，需要后续完善。
• flsuh_cache 方法名来自上游拼写错误，建议向上游提 issue 修正。

CI 状态

所有 CI 检查为 skipped 状态，mergeable_state=dirty。CI 跳过可能因 PR 基于 fork 的 feature 分支。无法从 CI 获取验证信息。

结论

前次审查指出的两个阻断性问题已在最新提交中全部修复，实现合理，代码质量可接受。批准合并。

Powered by glm-5.1

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。同时基于 feat/starry-ebpf 分支，包含 ebpf.rs、kprobe.rs、perf_event.rs 等前置代码。附带 7 个错误路径 C 测试用例。

前次审查问题修复状态

本 PR 已收到 3 次 CHANGES_REQUESTED 和 1 次 APPROVED 审查。最新提交 24086f94c 相对于已批准的 6ec4920d7 新增 3 个提交（仅在 ebpf.rs 中新增 +38/-5 行），已确认所有前次阻断性问题均已修复：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，与同目录下其他测试一致，测试运行器可正确发现 test-kmod-loader。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查。vmalloc 失败时返回安全的 NullSectionMem（返回 null 指针和 false），完全消除了 UB 风险。
3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来 delete_module 实现时的释放计划。

新增变更审查（6ec4920d7 → 24086f9）

新增变更仅涉及 ebpf.rs，包含两项改进：

1. BPF_LOOKUP_CACHE：新增全局静态缓存，helper_map_lookup_elem 现在将查找结果复制到缓存再返回指针，而非直接返回 map_ptr。这修复了之前直接返回 map fd 作为指针的错误行为，更接近 Linux bpf_map_lookup_elem 语义。SAFETY 注释正确说明了返回指针的有效期限制。

2. helper_probe_read 改进：添加了 4096 字节上限检查防止越界读取；对用户空间地址（< 0x8000_0000_0000）尝试通过 starry_vm::vm_read_slice 安全读取，失败时回退到原始拷贝。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计思路合理。
• NullSectionMem 作为 vmalloc 失败时的安全回退实现，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported。
• 系统调用路由在 syscall/mod.rs 中正确注册，同时将 bpf 和 perf_event_open 从 dummy_fd 移至实际处理。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel（11 features）全部通过
• ✅ cargo xtask starry build --arch x86_64 构建成功
• ✅ 合并冲突解决后（仅 Cargo.lock），上述验证重新通过

CI 状态

无 CI 检查运行（mergeable_state=dirty），CI 跳过可能因 PR 基于 fork feature 分支。

重复/重叠分析

• base 分支：origin/dev 上不存在任何 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，本 PR 的分支 feat/starry-kmod 基于此分支，属于前置依赖（partial-overlap），PR #849 是 PR #848 的超集。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了对此 PR 的依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

合并冲突

当前 mergeable_state=dirty。经本地验证，冲突仅在 Cargo.lock 中（其他文件自动合并成功）。解决方案：

git fetch origin
git merge origin/dev
# 解决 Cargo.lock 冲突：选择任一侧后运行 cargo generate-lockfile
git add Cargo.lock && git commit

已在本地完成冲突解决并验证（fmt/clippy/build 均通过），但无法推送到贡献者 fork。

建议性意见

1. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险（两个 CPU 同时执行 BPF helper 可能互相覆盖缓存指针），SAFETY 注释已说明此限制。后续可考虑 per-CPU 缓存解决。
2. helper_probe_read 中 0x8000_0000_0000 用户/内核地址分界线是硬编码假设，建议后续提取为平台相关常量。
3. flsuh_cache 方法名来自上游 kmod-loader crate trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue 修正。

结论

代码质量已达到可合并标准，所有前次阻断性问题均已修复，本地验证全部通过。当前唯一阻塞项是 Cargo.lock 合并冲突，请作者 rebase 到最新 dev 后即可合并。

Powered by glm-5.1

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。同时基于 feat/starry-ebpf 分支，包含完整的 eBPF 子系统（ebpf.rs 1291 行、kprobe.rs 334 行、perf_event.rs 416 行）。附带 7 个错误路径 C 测试用例。最新提交 f542af1f3 新增了 BPF/perf_event fd 关闭与资源释放功能。

前次审查问题修复状态

本 PR 已收到 3 次 CHANGES_REQUESTED 和 1 次 APPROVED。所有阻断性问题均已在当前 head f542af1f3 中修复：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，与同目录下其他测试一致。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem（返回 null 指针和 false），完全消除了 UB 风险。
3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来释放计划。

新增变更审查（相对于已批准的 6ec4920d7）

最新 3 个提交新增了以下改进：

1. BPF_LOOKUP_CACHE：helper_map_lookup_elem 将查找结果复制到缓存再返回指针，而非直接返回 map 内部指针，更接近 Linux bpf_map_lookup_elem 语义。
2. helper_probe_read 改进：添加 4096 字节上限防止越界读取；对用户空间地址尝试通过 vm_read_slice 安全读取。
3. BPF fd 关闭与资源释放：新增 BpfFdTable::close_fd、remove_map、remove_prog、handle_obj_close（BPF_OBJ_CLOSE 命令），以及 perf_event_close、perf_event_fd_exists 辅助函数，解决了 fd 泄漏问题。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache。
• NullSectionMem 作为 vmalloc 失败时的安全回退实现，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported。
• eBPF 解释器实现了完整的 BPF 指令集，支持 Array/Hash map、多种 helper 函数。
• 系统调用路由正确注册了 bpf、perf_event_open、init_module、delete_module、finit_module。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel（11 features）全部通过
• ✅ cargo xtask starry build --arch x86_64 构建成功

CI 状态

无 CI 检查运行（mergeable_state=dirty），CI 跳过可能因 PR 基于 fork feature 分支。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，本 PR 分支基于此，属于前置依赖（partial-overlap）。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

合并冲突

当前 mergeable_state=dirty，冲突在 Cargo.lock 中。请作者 rebase 到最新 dev 后即可合并。

建议性意见

1. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险（两个 CPU 同时执行 BPF helper 可能互相覆盖缓存），SAFETY 注释已说明限制。后续可考虑 per-CPU 缓存。
2. helper_probe_read 中 0x8000_0000_0000 用户/内核地址分界线是硬编码假设，建议后续提取为平台相关常量。
3. flsuh_cache 方法名来自上游 kmod-loader crate trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue。

结论

代码质量已达到可合并标准。所有前次阻断性问题均已修复，最新提交进一步完善了资源管理，本地验证全部通过。当前唯一阻塞项是 Cargo.lock 合并冲突，请作者 rebase 到最新 dev 后即可合并。

Powered by glm-5.1

[mai-team-app]

💡 建议：BPF_LOOKUP_CACHE 是全局静态，在 SMP 场景下两个 CPU 同时执行 BPF helper map_lookup_elem 时可能互相覆盖缓存内容。当前 SAFETY 注释已说明此限制。后续可考虑使用 per-CPU 缓存（如 ax_hal::percpu ）来消除竞态风险。

[mai-team-app]

💡 建议：0x8000_0000_0000 作为用户/内核地址分界线是 x86_64 特定的硬编码假设。如果未来需要在 riscv64 或 aarch64 上运行 eBPF 程序，此值可能不正确。建议后续提取为平台相关常量（如 arch::USER_SPACE_END）。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。同时包含完整的 eBPF 子系统（ebpf.rs、kprobe.rs、perf_event.rs）。附带错误路径 C 测试用例。

前次审查问题修复状态

前 3 次 CHANGES_REQUESTED 指出的两个阻断性问题已在当前 head 中修复：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，测试运行器可正确发现。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem。
3. ✅ forget 注释：已添加说明意图和未来释放计划。

本地验证结果

• ❌ cargo fmt --check 失败：trap.rs 和 task/mod.rs 中 #[cfg(...)] 属性格式不符合 rustfmt 规范
• ❌ cargo xtask clippy --package starry-kernel 全部 12 个 feature 检查失败：lib.rs 中 mod ebpf; 被重复声明两次（第 21 行和第 27 行），导致编译错误 E0428: the name 'ebpf' is defined multiple times

阻断性问题

1. 🐛 lib.rs 中 mod ebpf; 重复声明：第 21 行和第 27 行各有一处 mod ebpf;，导致所有 feature 编译均失败。这是最新提交 30e13966 引入的回归。修复方式：删除第 27 行多余的 mod ebpf;。

2. ⚠️ cargo fmt --check 失败：trap.rs 中 #[cfg(all(feature = "kprobe", any(...)))] 格式不符合 rustfmt 规范，task/mod.rs 中有相同的格式问题。请运行 cargo fmt 修复。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module、ebpf、kprobe 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，本 PR 分支基于此，属于前置依赖（partial-overlap）。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

CI 状态

无 CI 检查运行（mergeable_state=dirty），CI 跳过可能因 PR 基于 fork feature 分支。

建议性意见

1. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险，SAFETY 注释已说明限制，后续可考虑 per-CPU 缓存。
2. flsuh_cache 方法名来自上游 kmod-loader crate（拼写错误），本 PR 实现正确，可考虑向上游提 issue。

结论

前次审查的阻断性问题已全部修复，但最新提交引入了新的编译阻断（mod ebpf; 重复声明）和格式问题。需要修复后方可合并。

Powered by mimo-v2.5-pro

Powered by glm-5.1

[mai-team-app]

🐛 阻断：mod ebpf; 重复声明

ebpf 模块已在第 21 行声明过，此处重复声明导致编译失败：

error[E0428]: the name `ebpf` is defined multiple times
  --> os/StarryOS/kernel/src/lib.rs:27:1

所有 12 个 feature 的 clippy 检查均因此失败。

修复方式：删除此行。

[mai-team-app]

⚠️ cargo fmt 格式不符

此处的 #[cfg(all(feature = "kprobe", any(target_arch = "x86_64", target_arch = "riscv64", target_arch = "aarch64")))] 属性应按 rustfmt 规范拆分为多行格式。请运行 cargo fmt 自动修复。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。同时包含完整的 eBPF 子系统（ebpf.rs 1334 行、kprobe.rs 474 行、perf_event.rs 430 行）以及对应测试用例。

前次审查问题修复状态

本 PR 已收到多次审查（多次 CHANGES_REQUESTED 和 APPROVED）。当前 head fd533ecc 中所有阻断性问题均已修复：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，与同目录下其他测试一致。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem（no-op 实现），完全消除了 UB 风险。
3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来 delete_module 实现时的释放计划。
4. ✅ mod ebpf; 重复声明：已修复，lib.rs 中仅有一处 mod ebpf;。
5. ✅ cargo fmt 格式问题：lib.rs 模块声明已在字母序。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel（12 features）全部通过，0 失败

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计思路合理。
• NullSectionMem 作为 vmalloc 失败时的安全回退实现，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported，待后续完善。
• eBPF 解释器实现了完整的 BPF 指令集（ALU/JMP/MEM），支持 Array/Hash map、11 个 helper 函数。
• 系统调用路由正确注册了 bpf、perf_event_open、init_module、delete_module、finit_module。
• BpfFdTable 实现了 fd 分配/回收（含 free-fd 重用）和 close_fd 资源释放。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module、ebpf、kprobe 相关代码，属于全新功能。
• PR #847（同一作者）：kprobe 子系统支持，本 PR 依赖其分支，属于前置依赖。
• PR #848（同一作者）：eBPF 子系统，本 PR 分支基于此，属于前置依赖（partial-overlap）。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

CI 状态

无 CI 检查运行（mergeable_state=unstable），CI 跳过可能因 PR 基于 fork feature 分支。无法从 CI 获取验证信息，本地验证全部通过。

建议性意见（非阻断）

1. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险（两个 CPU 同时执行 BPF helper 可能互相覆盖缓存），SAFETY 注释已说明限制。后续可考虑 per-CPU 缓存。
2. helper_probe_read 中用户/内核地址分界线 0x8000_0000_0000 是硬编码假设，建议后续提取为平台相关常量。
3. flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue。

结论

前次审查指出的所有阻断性问题均在当前 head fd533ecc 中修复。代码质量达到可合并标准，本地验证（fmt/clippy）全部通过。批准合并。

Powered by glm-5.1

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。同时基于 feat/starry-ebpf 分支，包含完整的 eBPF 子系统（ebpf.rs、kprobe.rs、perf_event.rs）。附带 7 个错误路径 C 测试用例。

前次审查问题修复状态

本 PR 已收到 7 次审查（4 次 CHANGES_REQUESTED、2 次 APPROVED、1 次 COMMENTED）。当前 head 4defa4105 修复状态：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，与同目录下其他测试一致，测试运行器可正确发现。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem（返回 null 指针和 false），完全消除 UB 风险。
3. ✅ mod ebpf; 重复声明：已修复，lib.rs 中仅有一处声明。
4. ✅ forget 注释：已添加说明意图和未来释放计划。
5. ✅ cargo fmt --check：当前 head 通过格式检查。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache。
• NullSectionMem 作为 vmalloc 失败时的安全回退，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported。
• 系统调用路由在 syscall/mod.rs 中正确注册。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel（13 features）全部通过
• ✅ cargo xtask starry build --arch x86_64 构建成功

CI 状态

所有 CI 检查为 skipped（PR 基于 fork 的 feature 分支，不满足 CI 触发条件），与 PR 无关。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848：eBPF 子系统，本 PR 分支基于此，属于前置依赖（partial-overlap）。
• PR #837：kallsyms 符号表，resolve_symbol 桩实现声明了依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

合并冲突

当前 mergeable_state=true，mergeable=true，rebaseable=true，无合并冲突。

建议性意见

1. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险（SAFETY 注释已说明限制），后续可考虑 per-CPU 缓存。
2. flsuh_cache 方法名来自上游 kmod-loader crate trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue。
3. resolve_symbol 为桩实现返回 None，待 PR #837 合并后启用完整符号解析。

结论

所有前次阻断性问题均已修复，本地验证全部通过（fmt/clippy/build），无合并冲突。代码质量达到可合并标准，批准合并。

Powered by glm-5.1

[ZR233]

请处理冲突

[CN-TangLin]

冲突已解决，已 rebase 到最新 dev 分支（#847 kprobe + #848 eBPF 已合并）。

主要处理：

• 跳过了与 feat(starry-kernel): add kprobe support #847 和 feat(starry-kernel): add eBPF subsystem (maps, VM, helpers, perf events) #848 重复的 kprobe/eBPF commit
• 解决了 lib.rs、syscall/mod.rs、Cargo.toml 的合并冲突
• 更新了 ax_hal → ax_runtime::hal 路径引用
• 移除了不存在的 dw_apb_uart workspace 依赖

已通过 cargo fmt。CI 会从零编译验证。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。新增 kmod_loader.rs（229 行）包含页对齐内存分配、ELF section 权限映射、NullSectionMem 安全回退和系统调用入口。同时包含对 ebpf.rs 的一个小修复和 perf_event.rs 的 cfg guard。附带 10 个错误路径 C 测试用例。

前次审查问题修复状态

本 PR 已收到 8 次审查（多次 CHANGES_REQUESTED 和 APPROVED）。当前 head 0013cdb80 已修复所有历史阻断性问题：

1. ✅ 测试安装路径：CMakeLists.txt 已正确安装到 usr/bin/starry-test-suit，与同目录其他测试一致。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem（实现 SectionMemOps trait，返回 null 指针和 false）。
3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来 delete_module 实现时的释放计划。
4. ✅ mod ebpf; 重复声明：已修复，lib.rs 中各模块声明唯一。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换，TLB/icache 刷新在释放地址空间锁后进行，锁粒度合理。
• NullSectionMem 作为 vmalloc 失败时的安全 no-op 回退，避免内核崩溃。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported，待后续完善。
• resolve_symbol 使用 AtomicBool 确保仅打印一次警告，避免日志刷屏。
• flsuh_cache 中 aarch64 专用 dcache 清理和通用 icache flush 的组合处理得当。
• perf_event.rs 添加 #[cfg(feature = "ebpf")] 保护，避免非 ebpf feature 下编译错误。
• ebpf.rs 中 BPF 验证器将 BPF_CALL_OP 替换为字面量 0x80，语义相同但降低了可读性（见建议）。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel（14 feature 组合）全部通过，无 warning
• ✅ PR head SHA 与 checkout 一致：0013cdb802be59c1f0f3c9de91110f05d14201ce

CI 状态

所有 CI 检查均为 skipped 状态（可能因 PR 基于 fork 的 feature 分支不满足 CI 触发条件）。无 CI 失败与本 PR 相关。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module 相关代码，属于全新功能。
• PR #848（同一作者）：eBPF 子系统，已合并到 dev，本 PR 不再包含其重复代码。
• PR #837（Godones）：kallsyms 符号表支持，本 PR 的 resolve_symbol 桩实现声明了对此 PR 的依赖，属于互补关系。
• 结论：无重复实现，与相关 PR 关系明确。

建议性意见

1. ebpf.rs 中 op != 0x80 使用字面量替代了之前的 bpf_insn::BPF_CALL_OP 常量引用，建议保持使用常量以提高可读性，虽然语义相同。
2. BPF_LOOKUP_CACHE 在 SMP 场景下存在竞态风险（两个 CPU 同时执行 BPF helper 可能互相覆盖缓存），SAFETY 注释已说明限制，后续可考虑 per-CPU 缓存。
3. flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue 修正。

结论

所有历史阻断性问题均已修复，代码质量达到可合并标准。cargo fmt --check 和 clippy 全部通过。批准合并。

Powered by mimo-v2.5-pro

[CN-TangLin]

关于模块声明顺序和 trap.rs 格式问题：已在之前的 rebase commit 中修复。当前 cargo fmt --check 通过，模块顺序符合 rustfmt 字母序要求。

[mai-team-app]

PR 审查：feat(starry-kernel): add LKM support via kmod-loader integration

变更概述

本 PR 为 StarryOS 内核添加可加载内核模块（LKM）支持，集成 kmod-loader crate（v0.2），实现 init_module / delete_module / finit_module 系统调用。新增 kmod_loader.rs（229 行）包含页对齐内存分配 KmodSectionMem、null 安全回退 NullSectionMem、StarryKmodHelper 实现和系统调用入口。同时附带 10 个错误路径 C 测试用例和 3 个 x86_64 链接脚本。

实现逻辑

• KmodSectionMem 通过全局分配器实现页对齐内存分配，change_perms 通过页表操作实现 R/W/X 权限切换并刷新 TLB/icache，设计合理。
• NullSectionMem 作为 vmalloc 失败时的安全回退实现，避免内核崩溃。Drop 已添加 null 检查，完全消除了 UB 风险。
• sys_init_module 从用户空间读取 ELF 数据和参数字符串，调用 kmod-loader 加载并执行模块 init 函数后 forget 使模块常驻内存，符合当前无卸载设计，已添加意图注释。
• resolve_symbol 使用 AtomicBool 确保仅输出一次警告，等待 PR #837（kallsyms）支持完整符号解析。
• sys_delete_module / sys_finit_module 为桩实现返回 Unsupported，待后续完善。
• 系统调用路由在 syscall/mod.rs 中正确注册 init_module、delete_module、finit_module。
• perf_event.rs 新增 #[cfg(feature = "ebpf")] 条件编译守卫，避免无 eBPF feature 时编译错误。
• ebpf.rs 验证器中将 bpf_insn::BPF_CALL_OP 替换为字面量 0x80（值相同），不影响逻辑正确性，但执行路径（第 1181 行）仍使用 BPF_CALL_OP 常量，存在轻微风格不一致。

前次审查问题修复状态

本 PR 已收到多次审查（多次 CHANGES_REQUESTED 和 APPROVED）。当前 head a8f36bbf1 已修复全部前次阻断性问题：

1. ✅ 测试安装路径：CMakeLists.txt 已修改为安装到 usr/bin/starry-test-suit，与同目录下其他测试一致。
2. ✅ KmodSectionMem null 指针 Drop UB：Drop 已添加 if !self.ptr.is_null() 检查；vmalloc 失败时返回安全的 NullSectionMem。
3. ✅ forget 注释：已添加说明 core::mem::forget(owner) 的意图和未来 delete_module 实现时的释放计划。
4. ✅ mod ebpf; 重复声明：当前 lib.rs 中仅有一处 mod kmod_loader;，模块声明按字母序排列。

本地验证结果

• ✅ cargo fmt --check 通过
• ✅ cargo xtask clippy --package starry-kernel 全部 14 个 feature 检查通过
• ✅ 无合并冲突（mergeable=true，mergeable_state=blocked 为分支保护规则所致，非代码冲突）

CI 状态

多数 CI 检查为 skipped 状态（PR 基于 fork feature 分支，可能不满足 CI 触发条件），部分为 queued/in_progress。未观察到失败的检查。

重复/重叠分析

• base 分支：origin/dev 上不存在 kmod_loader、init_module 相关代码，属于全新功能。
• PR #837（Godones，kallsyms）：✅ 已合并到 dev，resolve_symbol 桩实现声明了对此 PR 的依赖，后续可通过 feature gate 启用完整符号解析。
• PR #848（CN-TangLin，eBPF）：✅ 已合并到 dev，本 PR 当前 head 已 rebase 到包含 eBPF 和 kprobe 的最新 dev。
• 结论：本 PR 无重复实现，与相关 PR 关系明确（前置依赖已合并）。

已知限制（非阻断）

• resolve_symbol 当前为桩实现返回 None，待启用 kallsyms 完整符号解析。
• delete_module 和 finit_module 为 stub，需要后续完善。
• flsuh_cache 方法名来自上游 kmod-loader crate 的 trait 定义（拼写错误），本 PR 实现正确，可考虑向上游提 issue 修正。
• ebpf.rs 验证器中 0x80 字面量与执行路径 BPF_CALL_OP 常量存在轻微风格不一致，不影响功能。

结论

所有前次阻断性问题均已修复，代码质量达到可合并标准，本地验证全部通过。批准合并。

Powered by mimo-v2.5-pro

[CN-TangLin]

@ZR233 冲突已解决，已 rebase 到最新 dev 分支（#847 kprobe + #848 eBPF 已合并）。感谢及时提醒