Collect bpf helper arguments related to bpf map #453
+261
−20
Conversation
This file contains 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
|
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 |
jschwinger233
force-pushed
the
gray/bpf-map-args
branch
from
4e3f4c3 to
e6de8f9
Compare
jschwinger233
force-pushed
the
gray/bpf-map-args
branch
4 times, most recently
from
8fb88e5 to
8cb08f5
Compare
jschwinger233
changed the title
|
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 |
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 <gray.liang@isovalent.com>
No functional changes. Signed-off-by: gray <gray.liang@isovalent.com>
This patch collects bpfmap id, name, key, value at bpf_map_update_elem. Signed-off-by: gray <gray.liang@isovalent.com>
This patch collects bpfmap id, name, key, value at bpf_map_delete_elem. Signed-off-by: gray <gray.liang@isovalent.com>
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 <gray.liang@isovalent.com>
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 <gray.liang@isovalent.com>
Signed-off-by: gray <gray.liang@isovalent.com>
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 <gray.liang@isovalent.com>
jschwinger233
force-pushed
the
gray/bpf-map-args
branch
from
8cb08f5 to
e93d1fa
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds
--output-bpfmapflag to collect and print bpfmap ID, name, key(hex) and value(hex).Fixes: #448