feat: generic probe support#953
Conversation
| ProgName string | ||
| } | ||
|
|
||
| func ParseProbe(spec string) (*ProbeSpec, error) { |
There was a problem hiding this comment.
Should we cover USDTs here as well?
There was a problem hiding this comment.
Yeah. good idea. can we do that in a follow up PR?
from a quick look, i failed trying to find any support for this in cilium/ebpf. looks like we would need to parse SDT notes, and then, in certain cases, based on https://www.sourceware.org/systemtap/wiki/UserSpaceProbeImplementation, deal with semaphores ourselves?
There was a problem hiding this comment.
worth noting that i also looked into adding support for generic tracepoints but was not trivial either because we need struct pt_regs *.
my guess is that we could maybe do something like what happens here, but then that would only get us support for tracepoints on syscalls
| } | ||
|
|
||
| // uprobe__generic serves as entry point for uprobe based profiling. | ||
| SEC("uprobe/generic") |
There was a problem hiding this comment.
Following feedback from #651 (comment), we should be able to skip uprobe/generic and just use kprobe/generic and attach it acccordingly.
There was a problem hiding this comment.
oh yeah. good point. change it in e7dd520 to make use of kprobe/generic for all types
| } | ||
|
|
||
| func ParseProbe(spec string) (*ProbeSpec, error) { | ||
| parts := strings.SplitN(spec, ":", 3) |
There was a problem hiding this comment.
As we handle here user input, should we handle the case where capitalized letters are input?
There was a problem hiding this comment.
not sure how much further we want to get into parsing the user input.
In last rev i added https://github.com/Shopify/opentelemetry-ebpf-profiler/blob/2e9f35d274a89f8e96c1f79d07b331244e496eca/tracer/probe.go#L75 to make sure the probe type is always lower case before any comparison.
As for the other parts of the input, i feel that is a concern of the link pkg. with an invalid probe name, we get something like the error msg below which feels like the right behaviour to me:
{"level":"error","msg":"failed to attach probes: creating perf_kprobe PMU (arch-specific fallback for \"do_WP_page\"): token __x64_do_WP_page: not found: no such file or directory","time":"2025-11-14T14:07:17.902603356Z"}
There was a problem hiding this comment.
no strong opinions here. strings.ToLower() is always a good start and for the rest pkg link will return an error if it does not fit.
|
|
||
| default: | ||
| return nil, fmt.Errorf("unsupported probe type: %s", probeTypeStr) | ||
| } |
There was a problem hiding this comment.
This can never happen (also maybe some linters can warn if we don't have a default here but do not exhaustively check all values for this type)
| default: | |
| return nil, fmt.Errorf("unsupported probe type: %s", probeTypeStr) | |
| } | |
| } |
There was a problem hiding this comment.
without this golang complains about the missing return. I could just move it out of the switch. just not sure it makes much of a difference
tracer/probe.go:115:1: missing return
|
@manuelfelipe Can you resolve conflicts? |
Rename uprobe-specific code to generic probe terminology and add support for kprobes alongside uprobes. Update probe-ctrl tool to handle both probe types.
* Add docs to functions and fields from probe struct
Co-authored-by: Florian Lehner <florianl@users.noreply.github.com>
ba86928 to
b0807bd
Compare
|
done @christos68k. rebased against latest |
Co-authored-by: Florian Lehner <florianl@users.noreply.github.com>
Summary
Refactors probe infrastructure introduced in #651 to support kprobes, kretprobes, uprobes, and uretprobes through a unified interface with syntax inspired by
bpftrace. Previously only uprobes were supported.Motivation
We wanted to understand what causes shared memory pages to turn into private memory pages (copy-on-write) in our Ruby workers. Pitchfork workers start with everything shared post-fork but quickly grow private memory as requests come in.
Being able to attach kprobes to kernel functions like
do_wp_pageallows us to capture stack traces when CoW events occur, showing exactly which Ruby code is causing pages to be copied. This data could help us identify memory hotspots and optimization opportunities.Previous uprobe-only support limited profiling to user space functions. Adding kprobe support enables profiling kernel-level events (page faults, syscalls, etc.) alongside regular CPU profiling, giving a complete picture of system behavior.
What Changed
Renamed uprobe-specific code to generic probe terminology:
--uprobe-link→--probe-linkflagUProbeLinks→ProbeLinksconfigTraceOriginUProbe→TraceOriginProbesupport/ebpf/uprobe.ebpf.c→generic_probe.ebpf.cAdded kprobe support:
kprobe__genericeBPF entry pointtracer/probe.goEnhanced probe-ctrl tool:
--listflag to show loaded eBPF programsUsage
Running ^ locally, with traces going to devfiler: