On Wed, Jan 15, 2025 at 6:32 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Sat, Jan 11, 2025 at 10:45 PM Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
> >
> > The primary goal of this change is to enable tracing of inlined kernel
> > functions with BPF programs.
> >
> > Dynamic tracepoints can be created using tools like perf-probe, debugfs, or
> > similar utilities. For example:
> >
> > $ perf probe -a 'tcp_listendrop sk'
> > $ ls /sys/kernel/debug/tracing/events/probe/tcp_listendrop/
> > enable filter format hist id trigger
> >
> > Here, tcp_listendrop() is an example of an inlined kernel function.
> >
> > While these dynamic tracepoints are functional, they cannot be easily
> > attached to BPF programs. For instance, attempting to use them with
> > bpftrace results in the following error:
> >
> > $ bpftrace -l 'tracepoint:probe:*'
> > tracepoint:probe:tcp_listendrop
> >
> > $ bpftrace -e 'tracepoint:probe:tcp_listendrop {print(comm)}'
> > Attaching 1 probe...
> > ioctl(PERF_EVENT_IOC_SET_BPF): Invalid argument
> > ERROR: Error attaching probe: tracepoint:probe:tcp_listendrop
> >
> > The issue lies in how these dynamic tracepoints are implemented: despite
> > being exposed as tracepoints, they remain kprobe events internally. As a
> > result, loading them as a tracepoint program fails. Instead, they must be
> > loaded as kprobe programs.
> >
> > This change introduces support for such use cases in libbpf by adding a
> > new section: SEC("kprobe/SUBSYSTEM/PROBE")
> >
> > - Future work
> > Extend support for dynamic tracepoints in bpftrace.
>
> Seems like the primary motivation is bpftrace support, so let's start
> there.
I believe we should extend support for this feature in BCC as well.
Since this is a common and widely applicable feature, wouldn't it make
sense to include it directly in libbpf?
> I'm hesitant to include this in libbpf right now. The whole
> SEC("kprobe") that calls "attach_tracepoint()" underneath makes me
> uncomfortable.
I reused the bpf_program__attach_tracepoint() function, but if we
examine its implementation closely, we can see that it actually
creates a DECLARE_LIBBPF_OPTS(bpf_perf_event_opts, pe_opts); rather
than a bpf_tracepoint_opts.
If naming is a significant concern, it wouldn’t be difficult to
reimplement the same logic with a more appropriate name, such as
attach_kprobe_based_tracepoint().
>
> You can still attach to such dynamic probe today with pure libbpf
> (e.g., if bpftrace needs to do this, for example) by creating
> perf_event FD from tracefs' id, and then using
> bpf_program__attach_perf_event_opts() to attach to it. It will be on
> the user to use either tracepoint or kprobe BPF program for such
> attachment.
You're right—we can manually attach it in the tools, but if we can
make it auto-attachable in libbpf, why not take advantage of that and
simplify the process?
>
> Yes, this doesn't work "declaratively" with a nice SEC("...") syntax,
> but at least it's doable programmatically, and that's what matters for
> bpftrace.
--
Regards
Yafang
