feat(starry-kernel): eBPF kernel runtime (tracepoint / kprobe / perf)

[LorenzLorentz]

按 reviewer @Godones 意见,#886 已拆分:本 PR 现在只保留内核侧 eBPF 运行时。用户态 aya 程序将迁到 apps/starry/ebpf/ 单独成 PR(基于本 PR 栈式提交);kebpf 可加载模块 + bpf(2) 运行时注册待本 PR 合并后再单独提交。

变更内容(纯内核运行时,25 文件)

StarryOS 内核(os/StarryOS/kernel)

• perf ringbuf:mmap(perf_fd) 映射 BpfPerfEvent ringbuf 页,并锚定到 mmap VMA 防止 UAF;FileLike::device_mmap 增加 length 参数(所有实现同步更新)。
• kprobe on x86_64:handle_syscall / sys_getpid 加 #[inline(never)],使挂在其符号上的 kprobe 真正触发。
• raw tracepoint attach/detach 原子安全化。
• mm:write_kernel_text 在 stop_machine 内部加内核地址空间锁,保持 IRQ-save guard 的 LIFO 嵌套(探针 detach 时不再泄漏 IRQ-disabled 状态)。
• ebpf/transform、perf、sysfs 等配套面。

ArceOS 调度 tracepoint 基础设施

• axfeat / axtask 新增 tracepoint-hooks feature。
• axtask:SchedTracepoint 跨 crate hook(经 ax-crate-interface),在调度切换 / fork / exit 时触发 sched:* tracepoint。

说明

• bpf(2) 仍由内核内置 eBPF 运行时处理;让可加载模块接管 bpf(2) 的 syscall 注册表(kebpf)是后续单独 PR(避免与本 PR 在 syscall/mod.rs 冲突)。
• 本机已验证 cargo xtask starry build --arch x86_64 通过。

[mai-team-app]

概要

本 PR (PR-D) 将 Starry-OS/StarryOS:ebpf-kmod 的 7 个 aya 用户态 eBPF 程序移植到 tgoskits，配合 PR-A (#850) 的内核侧 eBPF 运行时，形成完整的"内核 + 用户" eBPF 栈。同时新增 cargo xtask starry user-ebpf 子命令替代源仓的 Makefile。

变更范围

• 用户态程序 (os/StarryOS/user/ebpf/): 7 个独立 workspace (kret, rawtp, mytrace, syscall_ebpf, upb, upb2, async_test)，字节级移植自源仓 user/musl/，aya 三件套结构保持
• xtask 子命令 (scripts/axbuild/src/starry/user_ebpf.rs): cargo xtask starry user-ebpf {list, build} 替代 Makefile
• 根 Cargo.toml: [workspace] exclude 摘出 7 个嵌套 workspace + [patch.crates-io] printf-compat 临时 patch (来自 PR-A)
• 内核侧代码 (来自 PR-A #850 的 stacked commits): ebpf/, perf/, tracepoint/, kprobe/, kallsyms 等 ~3370 行增量

验证

本地已验证:

• cargo test -p axbuild starry::user_ebpf — 5/5 通过
• cargo check -p axbuild — 编译通过
• cargo metadata --no-deps — 主 workspace 正确 exclude 7 个嵌套 workspace

发现

1. 格式化问题 (阻塞)

cargo fmt --check 发现 scripts/axbuild/src/starry/user_ebpf.rs:115 有格式偏差：bail!() 宏的 match 臂数组被 rustfmt 要求加大括号。PR 声明 cargo fmt --all -- --check 通过，但实际在主 workspace 级别检查存在偏差。需要 cargo fmt 后重新提交。

2. 合并冲突 (阻塞)

当前 mergeable_state = DIRTY，与 dev 分支存在冲突。PR 依赖于 PR-A (#850) 先合入。这个在 PR 描述中有记录，属于预期情况。

3. 构建验证受限 (非阻塞)

由于本环境缺少 bpf-linker、*-linux-musl-cc 交叉编译器和 musl target，无法实际构建 aya 程序。async_test 可以 cargo check 但也需要 nightly feature (breakpoint)。PR 描述对此有明确记录，需要 CI Linux runner 完成验证。

重复/重叠分析

• PR-A (#850): 内核侧 eBPF 运行时。本 PR (PR-D) 的 stacked parent，包含所有 kernel 变更。不重复。
• PR #673: tracepoint 基础设施。已包含在本 PR 的 stacked base 中。不重复。
• PR #805: kallsyms + kprobe + bpf stub。已被 PR-A 替换。不重复。
• base 分支 (origin/dev) 无 os/StarryOS/user/ebpf/ 目录，无重复实现。

代码质量

• xtask 实现清晰: clap 参数处理、arch 映射、程序白名单校验、--program/--all 互斥逻辑全部有单元测试覆盖
• 用户态程序是源仓的字节级移植，结构完整 (aya 三件套 + Cargo.lock 入库)
• README.md 详细记录了落点决策、构建方法、前置环境、已知限制
• exclude 而非 members 的选择正确 — cargo 不允许嵌套 workspace
• [patch.crates-io] printf-compat 注释充分说明了临时性质和删除条件

限制 (已知)

• upb/upb2 依赖 PR-A 的 uprobe 真正接通，目前返回 Unsupported
• 安装路径未定，需后续 PR 处理 rootfs hook

建议修复格式化问题后，等 PR-A (#850) 合入 dev 后 rebase 解决冲突，即可合入。

Powered by glm-5.1

[mai-team-app]

概要

本 PR (PR-D) 将 Starry-OS/StarryOS:ebpf-kmod 的 7 个 aya 用户态 eBPF 程序移植到 tgoskits，配合 PR-A (#850) 的内核侧 eBPF 运行时，形成完整的「内核 + 用户」 eBPF 栈。同时新增 cargo xtask starry user-ebpf 子命令替代源仓的 Makefile。

变更范围

PR-D 特有的变更集中在以下区域（不含 PR-A stacked commits 的内核侧代码）：

• 用户态程序 (os/StarryOS/user/ebpf/): 7 个独立 workspace (kret, rawtp, mytrace, syscall_ebpf, upb, upb2, async_test)，aya 三件套结构保持完整
• xtask 子命令 (scripts/axbuild/src/starry/user_ebpf.rs): 237 行，list / build 子命令，clap 参数处理清晰
• 根 Cargo.toml: [workspace] exclude 正确摘出 7 个嵌套 workspace
• .cargo/config.toml: 四架构 musl linker + target-feature 配置
• README.md: 详尽的落点决策记录、内核依赖矩阵、构建指引、已知限制

验证结果

cargo test -p axbuild starry::user_ebpf  → 5/5 通过
cargo fmt --check                        → 干净（前次 review 的 fmt 偏差已在 commit 21951c92c 修复）

本环境缺少 bpf-linker / *-linux-musl-cc / musl target，无法实际构建 aya 程序。PR 描述对此有明确记录，需要 CI Linux runner 完成验证。

代码质量

• xtask 实现清晰：clap 参数处理、arch 映射、程序白名单校验、--program/--all 互斥逻辑全部有单元测试覆盖 (5/5)
• exclude 而非 members 的选择正确 — cargo 不允许嵌套 workspace
• aya git deps 无个人 fork patch，与 crate-fork-audit 规则一致
• README 详细记录了落点决策、构建方法、前置环境、已知限制
• 用户态程序是源仓的字节级移植，aya 三件套结构 + Cargo.lock 入库保证 CI 复现

前次 review 反馈

前次 review (mai-team-app, REQUEST_CHANGES) 指出的格式化问题已在后续 commit 21951c92c style(starry-xtask): rustfmt user_ebpf.rs match arm 中修复，当前 cargo fmt --check 全 workspace 通过。

合并状态

mergeable_state = blocked — 预期行为，本 PR 依赖于 PR-A (#850) 先合入 dev。PR 描述已记录 rebase 计划。

重复/重叠分析

• PR-A (#850): 内核侧 eBPF 运行时。本 PR 的 stacked parent，不重复。
• PR #847 (kprobe)、PR #805 (kallsyms+kprobe+bpf stub)、PR #673 (tracepoint): 均在 stacked base 中，不属于本 PR 变更。
• dev 分支: 无 os/StarryOS/user/ebpf/ 目录，无已有用户态 eBPF 程序或 xtask user-ebpf 子命令。无重复。
• 无其他 open PR 涉及 eBPF 用户态程序移植。

限制（已知，非阻塞）

• upb / upb2 依赖 PR-A 的 uprobe 接通，目前返回 Unsupported
• 安装路径未定，需后续 PR 处理 rootfs hook
• 实际构建验证受限，需 CI runner

结论

PR-D 特有的代码（用户态程序 + xtask 子命令）质量良好，结构正确，测试覆盖充分，文档完整。前次 review 反馈已修复。唯一阻塞因素是 PR-A (#850) 先合入 dev，属于工作流正常依赖。推荐等 PR-A 合入后 rebase 再合入。

Powered by glm-5.1

[LorenzLorentz]

已经重新提交pr并处理冲突, 本地测试通过, 麻烦 @ZR233 和 @Godones 老师review

[mai-team-app]

本轮审查覆盖当前 head 613583f3b4d13d178a792d38e6e2e92e2bf91235。

变更范围：本 PR 不只是把 os/StarryOS/user/ebpf/ 下的 aya 用户态程序和 cargo xtask starry user-ebpf 接进来，还包含 sched tracepoint、mmap(perf_fd) ringbuf、eBPF demo QEMU case/CI workflow，以及与 #880 高度重叠的 kmod/hello/kebpf 模块改动。因此它会影响 StarryOS 的 bpf(2)/perf_event_open(2)、mmap 设备映射生命周期、调度 tracepoint fast path、test-suit 打包和 axbuild 行为，不是纯用户态示例的隔离变更。

CI/本地验证：GitHub Actions 当前 check suite 为 success。 本地验证了 cargo fmt --check、git diff --check、主 workspace 与 9 个 eBPF 子 workspace 的 cargo metadata --no-deps、cargo test -p axbuild starry::user_ebpf、cargo check -p axbuild、cargo clippy -p axbuild --lib -- -D warnings、cargo check -p async_test --manifest-path os/StarryOS/user/ebpf/async_test/Cargo.toml 均通过。额外尝试 cargo clippy -p axbuild --all-targets -- -D warnings 会在未改动的 scripts/axbuild/src/arceos/cbuild.rs 触发既有 items_after_test_module，不作为本 PR 判断依据。完整 user-ebpf build/QEMU eBPF demo 未在本容器跑完：当前环境仍缺 bpf-linker/musl 交叉工具链；不过下面的生命周期问题可以静态确认，且会影响新增 sched_trace perf ringbuf 路径。

历史评论：之前 bot 指出的 rustfmt 问题已修复；Godones 关于 tracepoint 定义位置的两条组织性建议仍未从代码形态上采纳，本轮不把它作为 correctness blocker。重复/重叠分析：base 分支已有 #850 的内核 eBPF runtime，但没有这些用户态 aya workspace；开放 PR #880 与本 PR 中的 kmod/hello/kebpf/module-build 提交存在明显重叠/stack 风险，合并前建议明确依赖/取舍或 rebase 到最终的 #880 状态，避免两个 PR 互相覆盖。

仍有一个阻塞问题：mmap(perf_fd) 返回的物理映射没有把 backing pages 的所有权锚到 VMA，关闭 fd 后会释放仍被用户地址空间映射的页，存在 use-after-free/内存破坏风险。请先修复后再合并。

Powered by gpt-5.5

[mai-team-app]

审查总结

本轮审查覆盖当前 head d97ab01afadd408e9f8e5afd3bd9088391b67b3c。

变更范围

本 PR 包含 PR-D 用户态 eBPF 程序 + PR-A 内核侧 tracepoint/perf 改动，以及 kmod 模块、eBPF QEMU test-suit 和 CI workflow。关键变更：

• 用户态 eBPF 程序 (os/StarryOS/user/ebpf/)：9 个独立 workspace（kret, rawtp, mytrace, syscall_ebpf, upb, upb2, async_test, sched_trace, profile），aya 三件套结构完整
• xtask 子命令 (scripts/axbuild/src/starry/user_ebpf.rs)：241 行，list/build 子命令，5/5 测试通过
• perf mmap 修复 (kernel/src/perf/{mod,bpf}.rs)：DeviceMmap::Physical(range, Some(anchor)) 用 Arc<GlobalPage> 保证 ringbuf 页生命周期不短于用户 VMA
• sched tracepoint (kernel/src/tracepoint/sched.rs, syscall/task/clone.rs, task/ops.rs)：sched_switch / sched_process_fork / sched_process_exit，定义紧邻发射点
• KernelExtTracePoint 从 Mutex 改 SpinNoPreempt：在 atomic context（switch_to、IRQ off）中 fire tracepoint 必须用非睡眠锁
• kmod 模块 + test-suit：hello/kebpf 加载模块、kmod-modules QEMU 测例
• eBPF QEMU test-suit：syscall_count / sched_trace / profile 三组，反 fallback 断言设计合理

前次 review 反馈处理

前次 review（mai-team-app[bot], REQUEST_CHANGES, 6/4）指出 mmap(perf_fd) 返回的物理映射没有锚到 VMA，存在 use-after-free。已修复：

• BpfPerfEventWrapper::device_mmap 返回 (PhysAddr, Arc<GlobalPage>)
• PerfEvent::device_mmap 线程 anchor 到 DeviceMmap::Physical(range, Some(anchor))
• 字段声明顺序（inner 在 pages 之前）保证 drop 顺序正确
• 注释完备，解释了 refcount 语义和生命周期保证

之前 bot 指出的 rustfmt 问题已在 commit 21951c92c 修复。

本地验证

cargo fmt --all -- --check          → 干净 ✅
cargo test -p axbuild starry::user_ebpf → 5/5 通过 ✅
cargo check -p axbuild              → 编译通过 ✅
cargo metadata --no-deps             → 主 workspace 218 packages，9 个 eBPF 程序正确 exclude ✅
cargo metadata --manifest-path os/StarryOS/user/ebpf/<prog>/Cargo.toml (9/9) → 全部 OK ✅

完整 user-ebpf build / QEMU eBPF demo 未在本容器跑完：缺 bpf-linker / musl 交叉工具链。但 mmap 修复可通过静态分析确认正确性，xtask 子命令测试覆盖充分。

CI 状态

GitHub Actions 当前 head SHA 的 check suite：

• Detect changed paths → success
• Check formatting / {run_host, run_container} → skipped（path-filtered）
• Run sync-lint / {run_host, run_container} → skipped/queued
• Run clippy / run_container → skipped
• 大量 Test * / Publish * → skipped（path-filtered，PR 改动面不影响这些 job）

CI skipped 均为 path-filter 预期行为，不构成阻塞。本 PR 改动面集中在 eBPF/kernel/xtask/test-suit，不影响 axvisor/starry 常规 CI 路径。

重复/重叠分析

• PR-A (#850)：内核侧 eBPF 运行时，本 PR stacked parent。不重复。
• PR #880（feat/starry-modules: hello + kebpf）：与本 PR 存在明显重叠——os/StarryOS/modules/{hello,kebpf}（6 文件 387 行）、kmod.rs 重构、kmod-modules 测例在两个 PR 中均出现。同一作者的 stacking 策略导致此重叠，建议明确合并顺序：先合 #880 再 rebase #886，或关闭 #880 合入本 PR。
• dev 分支：无 os/StarryOS/user/ebpf/ 目录，无重复。无其他 open PR 涉及 eBPF 用户态程序移植。
• 无 [patch.crates-io] 引入，aya deps 均为 git（aya 未发 crates.io），与项目规范一致。

代码质量

• xtask 实现清晰：arch 映射、程序白名单、--program/--all 互斥逻辑均有单元测试覆盖
• exclude 而非 members 的选择正确——cargo 不允许嵌套 workspace
• tracepoint 定义紧邻发射点（clone.rs、task/ops.rs），注册通过 link section，位置不影响发现
• SpinNoPreempt 替代 Mutex 有充分注释说明原因
• perf mmap 修复的 Arc anchor 机制设计合理，SAFETY 注释完整
• QEMU test-suit 脚本采用反 fallback 设计：getpid_spin 驱动确定性 workload，HashMap 计数断言有明确下限（≥100/500）
• OwnedEbpfVm 中 register_allowed_memory(0..u64::MAX) 的 TODO 为既有问题，不在本 PR 范围内

结论

前次 review 的阻塞问题（mmap UAF）已正确修复。PR-D 特有代码（用户态程序 + xtask + tracepoint + perf 修复 + test-suit）质量良好，测试覆盖充分，文档完整。#880 重叠属于同一作者的 stacking 策略，不影响本 PR 代码正确性。建议合入。

Powered by mimo-v2.5-pro

[mai-team-app]

审查总结

本轮审查覆盖当前 head 56e1d812ac（PR-A #850 stacked commits + PR-D 用户态程序 + kmod 模块 + eBPF QEMU 测例 + CI workflow）。

变更范围

• 用户态 eBPF 程序（os/StarryOS/user/ebpf/）：9 个独立 workspace（async_test, kret, rawtp, mytrace, syscall_ebpf, sched_trace, profile, upb, upb2），aya 三件套结构完整
• xtask 子命令（scripts/axbuild/src/starry/user_ebpf.rs）：241 行，list/build 子命令，5/5 测试通过
• perf mmap 生命周期修复（kernel/src/perf/{mod,bpf}.rs）：DeviceMmap::Physical(range, Some(anchor)) 用 Arc<GlobalPage> 保证 ringbuf 页生命周期不短于用户 VMA
• sched tracepoint（kernel/src/tracepoint/sched.rs、syscall/task/clone.rs、task/ops.rs）：sched_switch / sched_process_fork / sched_process_exit
• kmod 模块 + test-suit：hello/kebpf 加载模块、kmod-modules QEMU 测例
• eBPF QEMU test-suit：syscall_count / sched_trace / profile 三组
• CI workflow（starry-ebpf.yml）：定时/手动触发的 eBPF demo 构建

前次 review 反馈处理

• mmap UAF（前次 REQUEST_CHANGES）：已正确修复。BpfPerfEventWrapper::device_mmap 返回 (PhysAddr, Arc<GlobalPage>)，PerfEvent::device_mmap 线程 anchor 到 DeviceMmap::Physical(range, Some(anchor))。字段声明顺序（inner 在 pages 之前）保证 drop 顺序正确。
• rustfmt 偏差（更早 REQUEST_CHANGES）：已在 commit 21951c92c 修复。
• Godones 关于 tracepoint 定义位置的建议：组织性建议，tracepoint 用 link section 注册，物理位置不影响发现，不作为阻塞项。

本地验证

git diff --check                              → 干净 ✅
cargo test -p axbuild starry::user_ebpf       → 5/5 通过 ✅
cargo metadata --no-deps                       → 218 packages，9 个 eBPF 程序正确 exclude ✅
grep [patch.crates-io] Cargo.toml              → 无 ✅

完整 user-ebpf build / QEMU eBPF demo 未在本容器跑完：缺 bpf-linker / musl 交叉工具链。PR 描述对此有明确记录，需 CI Linux runner 完成。

CI 状态

GitHub Actions 对 head 56e1d812a 的 check suite：大部分 job 为 skipped，属于 path-filter 预期行为（eBPF 改动面不影响 axvisor/starry 标准 CI 路径）。无 failure 结论。新增的 starry-ebpf.yml 为 schedule/workflow_dispatch 触发，不在 PR check 中体现。

重复/重叠分析

• PR-A (#850)：内核侧 eBPF 运行时，本 PR stacked parent。不重复。
• PR #880（feat/starry-modules: hello + kebpf）：与本 PR 存在 partial-overlap —— os/StarryOS/modules/{hello,kebpf}、kmod.rs、kmod-modules 测例在两个 PR 中均出现。同一作者的 stacking 策略，#886 是 superset。建议合并顺序：先合 #880 再 rebase #886，或关闭 #880 直接合入本 PR。
• dev 分支：无 os/StarryOS/user/ebpf/ 目录，无重复。无其他 open PR 涉及 eBPF 用户态程序移植。
• 无 [patch.crates-io] 引入，aya deps 均为 git（aya 未发 crates.io），与项目规范一致。

代码质量

• xtask 实现清晰：arch 映射、程序白名单、--program/--all 互斥逻辑均有单元测试覆盖
• exclude 而非 members 的选择正确——cargo 不允许嵌套 workspace
• tracepoint 定义紧邻发射点（clone.rs、task/ops.rs），注册通过 link section
• perf mmap 的 Arc anchor 机制设计合理，注释完整解释了 refcount 语义
• QEMU test-suit 脚本采用反 fallback 设计：getpid_spin 驱动确定性 workload，HashMap 计数断言有明确下限（≥100/500）
• STARRY_KMOD 构建模式的 codegen flags 隔离设计合理：通过 build config [env] 表局部启用，不影响其他测例

合并状态

mergeable_state = blocked — 预期行为，依赖 PR-A (#850) 先合入 dev。PR 描述已记录 rebase 计划。

结论

前次 review 的阻塞问题（mmap UAF）已正确修复。PR-D 特有代码质量良好，测试覆盖充分，文档完整。建议合入（在 PR-A #850 合入 dev 并 rebase 后）。

Powered by mimo-v2.5-pro

[ZR233]

复审当前 head 56e1d812ac25fb6567d00513a4be7d4d9cda087d，本轮结论为 REQUEST_CHANGES。主要原因不是代码风格，而是这个 PR 现在已经加入了 test-suit/starryos/ebpf 的 QEMU 用例和 eBPF demo workflow，但当前 head 没有一条可追溯的通过路径能证明这些新增用例真的可运行。

阻塞点：

1. 新增 eBPF QEMU 用例没有当前 head 的可复现通过证据。我运行了实际用例路径：

cargo xtask starry test qemu --test-group ebpf --arch x86_64 -c syscall_count

它在进入 guest 前失败：test-suit/starryos/ebpf/qemu-smp1/syscall_count/c/CMakeLists.txt 调用 cargo xtask starry user-ebpf build --program syscall_ebpf --arch x86_64，随后 syscall_ebpf-ebpf/build.rs 因找不到 bpf-linker panic，错误为 CannotFindBinaryPath，最终摘要是 FAIL syscall_count / 0/1 case(s) passed。本地环境确实缺 bpf-linker，但这个 PR 新增的 .github/workflows/starry-ebpf.yml 目前只有 schedule 和 workflow_dispatch，不在当前 PR check 中运行；gh run list --branch feat/starry-ebpf-userspace 只看到常规 CI workflow，且该新 workflow 还不能作为默认分支上的命名 workflow 查询。因此 merge 前需要把 eBPF demo suite 接入可见的 PR 校验，或提供当前 head 上可追溯的 workflow/run artifact，证明至少 cargo xtask starry test qemu --arch x86_64 -g ebpf 通过。

2. PR 描述已经明显落后于当前 diff。正文仍写“7 个程序”和 7/7 program workspace，但当前代码里 scripts/axbuild/src/starry/user_ebpf.rs 的 PROGRAMS 是 9 个（新增/包含 sched_trace、profile），并且当前 PR 还包含 kmod modules、kmod-modules normal QEMU case、三组 eBPF QEMU cases、perf/tracepoint runtime 修改和 starry-ebpf.yml。请同步 PR 描述和验证清单，否则 review/merge 依据会和实际变更不一致。

本轮已通过的本地检查：

git diff --check origin/dev...HEAD
audited clean
cargo fmt --check
cargo test -p axbuild starry::user_ebpf
cargo check -p axbuild
cargo xtask clippy --package axbuild
cargo metadata --format-version=1 --no-deps
9 个 eBPF nested workspace 的 cargo metadata
cargo xtask clippy --package starry-kernel
cargo xtask starry user-ebpf list
cargo xtask starry user-ebpf build --program async_test --arch x86_64
cargo xtask starry test qemu --test-group normal --arch x86_64 -c kmod-modules

cargo xtask starry user-ebpf build --program kret --arch x86_64 也因缺 bpf-linker 失败，和上面的 eBPF QEMU case 失败原因一致。

CI 状态：当前 head 仍是 56e1d812ac25fb6567d00513a4be7d4d9cda087d；常规 CI 暂未看到 failure，但查询时仍有 Run clippy / run_host、Test starry riscv64 qemu / run_host、Test starry aarch64 qemu / run_host、Test arceos riscv64 qemu / run_host pending。常规 CI 没有覆盖新增的 starry-ebpf.yml eBPF demo suite。

重复/重叠检查：dev 上没有 os/StarryOS/user/ebpf/；open PR 中 #880 与本 PR 在 os/StarryOS/modules/{hello,kebpf}、scripts/axbuild/src/starry/kmod.rs、kmod-modules test-suit 上存在 partial overlap，#886 更像 superset。建议明确 merge 顺序：先合 #880 后 rebase #886，或关闭 #880 并以 #886 承载这部分内容。

已处理的 review threads：已确认并 resolve 前次 bot 的 rustfmt 和 perf mmap retain/UAF 两个 fixed threads；Godones 关于 tracepoint 定义位置的 thread 保持打开，交给对应领域维护者判断。

[ZR233]

上次审查后作者新增了 4 个 commit：

1. uprobe 实现：新增 uprobe/mod.rs，支持用户态动态探针。设计合理：
   • 每进程独立的 uprobe manager（用户地址空间隔离）
   • 异常上下文使用 try_lock()（IRQ 禁用，不能睡眠）
   • 复用 kprobe 基础设施做指令解码和 out-of-line 单步执行
2. 端到端连接：将 uprobe 接入 kretprobe/tracepoint attach 路径
3. perf ringbuf mmap 修复：非直连路径保持 side-effect-free
4. clippy 修复：将 uprobe 异常处理分支折叠为 match guards

变更 12 个文件，+447/-79。CI 全部通过（clippy、fmt、sync-lint 均成功）。

uprobe 实现质量高：文档注释解释了设计决策（为什么 try_lock、为什么 per-process manager），复用了现有 kprobe 架构。此 PR 也修复了阻塞依赖 PR #1132 的 clippy 错误。

审查通过。

[mai-team-app]

审查总结

本轮审查覆盖当前 head bf1276a9b（纯内核侧 eBPF 运行时，34 文件 +827/-91）。

变更范围

• perf ringbuf mmap 生命周期 (perf/bpf.rs、perf/mod.rs)：BpfPerfEventWrapper::device_mmap 使用 Arc<GlobalPage> 将 ringbuf 物理页锚定到 VMA，Weak 保证 fd 关闭后页仍存活。字段声明顺序（inner 在 pages 前）保证 drop 顺序正确。
• device_mmap 调用时序 (syscall/mm/mmap.rs)：仅在 MAP_SHARED 时探测 device_mmap，MAP_PRIVATE 永远走 file_mmap/CoW 路径。修复了前次 review 指出的副作用时序问题。
• write_kernel_text LIFO 锁嵌套 (mm/access.rs)：kernel_aspace 锁移入 stop_machine 闭包内部，保持 IRQ-save guard LIFO 嵌套。
• sched tracepoint (tracepoint/sched.rs、syscall/task/clone.rs、task/ops.rs、arceos/modules/axtask/)：通过 ax-crate-interface 实现跨 crate sched_switch/sched_process_fork/sched_process_exit，tracepoint 定义紧邻发射点。
• uprobe 支持 (uprobe/mod.rs、kprobe.rs、perf/kprobe.rs)：per-process uprobe manager，通过 direct-map alias 访问用户页。
• #[inline(never)] (ebpf/transform.rs、ebpf/map.rs、ebpf/prog.rs)：保证符号在 release 构建中不被内联消去，为可加载模块 .kallsyms 重定位做准备。
• sysfs event_source (pseudofs/sysfs.rs)：aya 需要读取 /sys/bus/event_source/devices/{kprobe,uprobe,tracepoint}/type。
• bpf_probe_read_kernel helper 别名 (ebpf/mod.rs)：helper id 113 别名到 4，匹配 aya 的 probe read 调用。
• FileLike::device_mmap 签名：增加 length 参数，所有现有实现同步更新。

前次 review 反馈处理

• mmap UAF（早期 REQUEST_CHANGES）：已正确修复。Arc<GlobalPage> + DeviceMmap::Physical(.., Some(anchor)) 设计合理。
• device_mmap 副作用时序（ZR233 REQUEST_CHANGES）：已修复。sys_mmap 中仅 MAP_SHARED 才调用 device_mmap，MAP_PRIVATE 不触发 ringbuf 分配。
• ZR233 要求拆分 eBPF QEMU 用例：用户态程序和 eBPF QEMU 测试已移至 #1132，本 PR 不再包含。✅
• Godones 建议移除 #[inline(never)]：组织性建议。注释和 #[inline(never)] 有实际作用（可加载模块符号重定位），不作为阻塞项。

本地验证

cargo fmt --check                    → 干净 ✅
git diff --check                     → 干净 ✅
cargo xtask clippy --package starry-kernel → 13/13 通过 ✅
grep [patch.crates-io] Cargo.toml    → 无 ✅

CI 状态

当前 head 的所有 GitHub Actions check 均为 skipped（path-filter 预期行为：内核 eBPF 改动面不影响 axvisor/starry 标准 CI 路径）。无 failure 结论。

重复/重叠分析

• PR-A (#850)：内核侧 eBPF 运行时基础，本 PR 的 stacked parent。不重复。
• PR #880（feat/starry-modules）：本 PR 已拆分移除 kmod 模块，不再与 #880 重叠。
• PR #1132：用户态 eBPF 程序（从本 PR 拆出），stacked on 本 PR。不重复。
• dev 分支：无 eBPF 内核运行时代码。无重复。
• 无 [patch.crates-io] 引入。

代码质量

• perf mmap 的 Arc/Weak 所有权模型设计合理，SAFETY 注释完整
• write_kernel_text LIFO 锁嵌套修复注释详尽，解释了 IRQ 状态泄漏根因
• sched tracepoint 的 def_interface/impl_interface 跨 crate 设计干净
• uprobe 的 try_lock() 在异常上下文中使用合理（IRQs disabled，arm 在 syscall 上下文）
• kprobe 的 copy_memory 通过 direct-map alias 访问用户页避免了 IRQ-off 时的 faultable 路径
• bpf_probe_read_kernel 别名（113→4）与 Linux 内核 helper 表一致

结论

前次 review 的阻塞问题均已正确修复。PR 已按要求拆分为纯内核侧运行时。代码质量良好，注释充分，无安全/正确性/性能问题。建议合入。

Powered by mimo-v2.5-pro

[LorenzLorentz]

已按 @Godones 本轮意见全部处理（head c8f3d94a5）：

1. syscall/mod.rs — probe 点改到 sysno
抽出 #[inline(never)] pub fn sysno(id: usize) -> Option<Sysno>，handle_syscall 去掉 #[inline(never)]、改为转调 sysno()。这样探针挂在 sysno 上时第一个参数寄存器直接持有 syscall id，demo 可直接读取，无需再解析 UserContext 指针。

2. 移除面向 kebpf 的 #[inline(never)] 及注释

• ebpf/map.rs unified_map()、ebpf/prog.rs Drop::drop、ebpf/transform.rs 全部 9 处 KernelAuxiliaryOps 回调：#[inline(never)] 与相关注释已删除（认同：kernel 与 kmod 同步内联即不产生符号依赖，当前不关注 kebpf）。
• ebpf/mod.rs handle_prog_load：删除 kebpf 单态化描述及无用的 _verifier_info 绑定。

3. kprobe.rs copy_memory
取不到目标任务时改为 .expect("Failed to get task for uprobe")（此前 return 后续 uprobe 设置仍会崩溃）。

4. kprobe.rs 路径过长
导入 ax_runtime::hal::paging::{MappingFlags, PageSize}，文件内长路径已全部替换为短名。

5. sched tracepoint 就近定义（上一轮）
sched_process_fork/sched_process_exit 已在 syscall/task/clone.rs / task/ops.rs 发射点就近定义（commit d97ab01af）。

本机验证：cargo xtask starry build --arch x86_64 通过，cargo fmt -p starry-kernel -- --check 干净。麻烦 @Godones 复审～

[mai-team-app]

审查总结

本轮审查覆盖当前 head c8f3d94a5e725b47d374fb0846e0adea6eba3cf7。PR 已按 @Godones 要求拆分为纯内核侧 eBPF 运行时（25+ 文件，净增 792 行），不再包含用户态 aya 程序或 kebpf 模块。

变更范围

• perf ringbuf mmap 生命周期修复（perf/bpf.rs、perf/mod.rs）：BpfPerfEventWrapper 使用 Weak<GlobalPage> / Arc<GlobalPage> 所有权模型。VMA 持有强引用，wrapper 持有弱引用。device_mmap 仅在 MAP_SHARED 时调用（mmap.rs），避免 MAP_PRIVATE 路径的副作用消耗 ringbuf 槽位。
• kprobe/uprobe 支持（kprobe.rs、uprobe/mod.rs）：实现 uprobe 的 copy_memory、set_writeable_for_address、alloc_user_exec_memory、free_user_exec_memory，通过内核 direct-map 别名读写用户页。每个进程有自己的 uprobe_manager（ProcessData）。
• sched tracepoint（tracepoint/sched.rs、syscall/task/clone.rs、task/ops.rs、axtask/）：通过 ax_crate_interface 跨 crate 的 sched_switch/sched_process_fork/sched_process_exit。
• write_kernel_text LIFO 锁嵌套修复（mm/access.rs）：将 kernel_aspace 锁获取移入 stop_machine 闭包内。
• device_mmap 签名变更：增加 length 参数，所有 FileLike 实现同步更新。
• sysno() 函数（syscall/mod.rs）：#[inline(never)] 使 kprobe 符号可达，第一参数寄存器直接持有 syscall id。
• sysfs event_source（pseudofs/sysfs.rs）：kprobe/uprobe/tracepoint perf type 节点。
• raw/tracepoint double downcast 修复（perf/raw_tracepoint.rs、perf/tracepoint.rs）。

前次 review 反馈处理

• mmap UAF（REQUEST_CHANGES）：已正确修复 ✅。Arc<GlobalPage> + DeviceMmap::Physical(.., Some(anchor)) + Weak 所有权模型设计合理。
• device_mmap 副作用时序（ZR233 REQUEST_CHANGES）：已修复 ✅。仅在 MAP_SHARED 时才调用 device_mmap，MAP_PRIVATE 走 file_mmap/CoW 路径。
• #[inline(never)] / kebpf 相关注释（Godones）：已全部移除 ✅。
• sysno() 函数（Godones 建议）：已按建议实现 ✅。
• kprobe.rs .expect() / 短导入路径（Godones）：已修复 ✅。
• tracepoint 定义就近（Godones）：sched_process_fork 在 clone.rs，sched_process_exit 在 ops.rs ✅。

所有未解决的 review thread 已在本轮 resolve。

本地验证

cargo fmt --check                       → 干净 ✅
cargo xtask clippy --package starry-kernel → 13/13 通过 ✅
git diff --check origin/dev...HEAD      → 干净 ✅
grep [patch.crates-io] Cargo.toml       → 无 ✅

CI 状态

GitHub Actions 对 head c8f3d94a5：

• Detect changed paths → success ✅
• 其余 ~20 个 Test/Publish/Check job → skipped（path-filter 预期行为，eBPF 改动面不影响标准 CI 路径）
• 无 failure 结论
• skipped 为 path-filter 预期行为，不构成阻塞

重复/重叠分析

• #850（内核侧 eBPF 运行时）：已在 dev 合并。本 PR 为增量不重复。
• #880（feat/starry-modules: hello + kebpf）：本 PR 现已完全移除 kmod 模块相关改动，不再与 #880 重叠。
• dev 分支：无 eBPF 内核运行时代码。无其他 open PR 涉及相同的内核 eBPF 运行时功能。
• 无 [patch.crates-io] 引入。

代码质量评估

• perf mmap 的 Arc/Weak 所有权模型设计合理：VMA 持有强引用保证页存活到 munmap/exit；弱引用使得 mmap 被放弃后 fd 可重新 mmap，对齐 Linux 语义。
• write_kernel_text 的 LIFO 锁嵌套修复有详尽注释。
• uprobe 的 per-process manager 使用 sleeping Mutex（arm/disarm 需要地址空间操作），exception handler 用 try_lock()（IRQ context 安全，单 CAS）。
• task/user.rs 中 uprobe 路由优先于 ptrace 处理，符合 Linux 行为。

结论

前次所有阻塞问题已正确修复。代码质量良好，注释充分，无安全/正确性/性能问题。建议合入。

Powered by mimo-v2.5-pro

[mai-team-app]

确认：当前代码仅在 MAP_SHARED 时调用 device_mmap，MAP_PRIVATE 永远走 file_mmap/CoW 路径。ZR233 指出的副作用时序问题已正确修复。

[mai-team-app]

is_mapped() 检查 strong_count() > 0 和实际 write_event 之间存在极小的 TOCTOU 窗口（SpinNoPreempt 下另一 CPU 可能 munmap 掉最后的强引用）。实际风险极低（需 allocator lock + 跨 CPU 竞争），与 Linux perf ringbuf 模式一致。建议未来考虑在 write_event 中 upgrade() 临时持有强引用以彻底消除竞态。非阻塞。

[mai-team-app]

try_lock() 在 exception context 中使用合理：arm/disarm 在 syscall context（同一任务），fire 在 exception context，锁在此时无竞争。注释充分。

[LorenzLorentz]

@ZR233 老师好, 我注意到目前您, @Godones 老师, 以及 Bot @mai-team-app 都已经 approve 这个pr, 能不能麻烦您把这个pr merge 一下