On Tue, Jan 7, 2025 at 8:16 PM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
>
> On Mon, Jan 06, 2025 at 10:32:15AM +0800, Yafang Shao wrote:
> > On Mon, Jan 6, 2025 at 8:16 AM Alexei Starovoitov
> > <alexei.starovoitov@xxxxxxxxx> wrote:
> > >
> > > On Sun, Jan 5, 2025 at 4:44 AM Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
> > > >
> > > > Dynamic tracepoints can be created using debugfs. For example:
> > > >
> > > > echo 'p:myprobe kernel_clone args' >> /sys/kernel/debug/tracing/kprobe_events
> > > >
> > > > This command creates a new tracepoint under debugfs:
> > > >
> > > > $ ls /sys/kernel/debug/tracing/events/kprobes/myprobe/
> > > > enable filter format hist id trigger
> > > >
> > > > Although this dynamic tracepoint appears as a tracepoint, it is internally
> > > > implemented as a kprobe. However, it must be attached as a tracepoint to
> > > > function correctly in certain contexts.
> > >
> > > Nack.
> > > There are multiple mechanisms to create kprobe/tp via text interfaces.
> > > We're not going to mix them with the programmatic libbpf api.
> >
> > It appears that bpftrace still lacks support for adding a kprobe/tp
> > and then attaching to it directly. Is that correct?
> > What do you think about introducing this mechanism into bpftrace? With
> > such a feature, we could easily attach to inlined kernel functions
> > using bpftrace.
>
> so with the 'echo .. > kprobe_events' you create kprobe which will be
> exported through tracefs together with other tracepoints and bpftrace
> sees it as another tracepoint.. but it's a kprobe :-\
exactly.
>
> how about we add support for kprobe section like SEC("kprobe/SUBSYSTEM/PROBE"),
> so in your case above it'd be SEC("kprobe/kprobes/myprobe")
This is similar to what I'm currently proposing:
SEC("dynamic_tp/kprobes/my_dynamic_tp")
My proposal requires only a 3-line change. In contrast, if we
implement it as you suggested, it may require significantly more code
changes. I prefer to introduce a new section, such as
SEC("dynamic_tracepoint/"), SEC("kprobe_tracepoint/"), or something
similar, for this special type of kprobe. However, if you believe
SEC("kprobe/SUBSYSTEM/PROBE") is a better approach, I’m happy to
implement it that way.
>
> then attach_kprobe would parse that out and use new new probe_attach_mode
> for bpf_program__attach_kprobe_opts to attach it correctly
Yes, that would be a great enhancement for tracing inlined kernel functions.
--
Regards
Yafang
