Fix get_cpu_id() to return actual CPU core instead of hardcoded 0#5
Merged
Conversation
get_cpu_id() was stubbed to always return 0 because aya-ebpf didn't appear to expose bpf_get_smp_processor_id. Turns out it does, via the re-exported bindings (helper #8), it's just #[doc(hidden)] so it doesn't show up in the generated docs. Every exported trace event was reporting cpu_id: 0 regardless of which core the sample was actually taken on. The TUI doesn't render per-CPU data so nobody noticed, but the Chrome Trace JSON was silently wrong. // ticktockbent
Owner
|
Thanks @TickTockBent ! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
get_cpu_id()in the eBPF program was stubbed to always return 0, with a comment saying aya-ebpf doesn't exposebpf_get_smp_processor_idyet. It actually does. The bindings re-export it throughpub use gen::*in the helpers module, but it's#[doc(hidden)]so it never shows up in the docs. Easy to miss.Impact
Every trace event has been reporting
cpu_id: 0regardless of which core the sample was taken on. The TUI doesn't display per-CPU data, so this was invisible there. But the Chrome Trace JSON export includescpu_idin the args for both BEGIN and END events, and that data was wrong.This is the same calling convention as
bpf_get_current_pid_tgid(helper #14) andbpf_ktime_get_ns(helper #5), both already used in the same file. Helper #8 has been available since Linux 3.18, well below hud's 5.8+ requirement.Change
3 lines in
hud-ebpf/src/main.rs. Add the import, replace the stub with the real call.-- mass cargo-culting since mass '09