-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect bpf helper arguments related to bpf map #453
base: main
Are you sure you want to change the base?
Conversation
I hope this helps me understand how Cilium CT works. Even after 18 months since onboarding, CT is still a mystery to me. |
👍 the idea |
4e3f4c3
to
e6de8f9
Compare
8fb88e5
to
8cb08f5
Compare
I labelled this "don't merge' because it's on the top of #477 which is pending. |
#477 has been merged. Could your rebase? Thanks |
8cb08f5
to
e93d1fa
Compare
This patch doesn't introduce any functional change but defines corresponding new fields and struct in both bpf and userspace programs. Signed-off-by: gray <[email protected]>
No functional changes. Signed-off-by: gray <[email protected]>
This patch collects bpfmap id, name, key, value at bpf_map_update_elem. Signed-off-by: gray <[email protected]>
This patch collects bpfmap id, name, key, value at bpf_map_delete_elem. Signed-off-by: gray <[email protected]>
We can only get the map value at return hook (kretprobe), that's why event instance has to be stashed in a PERCPU array (event_stash) temporarily at entry hook (kprobe) and retrieved at return hook (kretprobe), where we can read bpfmap value from %rax (x64). kretprobe_bpf_map_lookup_elem also needs to be excluded from pcap injection. Signed-off-by: gray <[email protected]>
We search BTF to find bpfmap funcs by first parameter of type "struct bpf_map *". Function name suffix determine which bpf program is attached to: - *_lookup_elem: {kprobe,kretprobe}_bpf_map_lookup_elem - *_update_elem: kprobe_bpf_map_lookup_elem - *_delete_elem: kprobe_bpf_map_delete_elem Signed-off-by: gray <[email protected]>
Signed-off-by: gray <[email protected]>
By adding 1 to bpf_get_smp_processor_id(), we can safely rely on "if event.PrintBpfmapId > 0" to decide whether there is bpfmap data to read. Signed-off-by: gray <[email protected]>
e93d1fa
to
2a387f0
Compare
@@ -340,7 +368,7 @@ static __always_inline u64 | |||
sync_fetch_and_add(void *id_map) { | |||
u32 *id = bpf_map_lookup_elem(id_map, &ZERO); | |||
if (id) | |||
return ((*id)++) | ((u64)bpf_get_smp_processor_id() << 32); | |||
return ((*id)++) | ((u64)(bpf_get_smp_processor_id() + 1) << 32); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this an off by one bug in the existing codebase?
This PR adds
--output-bpfmap
flag to collect and print bpfmap ID, name, key(hex) and value(hex).Fixes: #448