Questions on BPF_PROG_TYPE_TRACING & fentry/fexit

Questions on BPF_PROG_TYPE_TRACING & fentry/fexit

[Grant Seltzer Richman]

Hi there,

I'm looking to implement programs of type BPF_PROG_TYPE_TRACING to
replace kprobe/tracepoints because from what I can tell there's less
performance overhead. However, I'm trying to understand restrictions
and use cases.

I see that there's a generic `bpf_program__attach()` which can be used
to attach programs and it will attempt to auto-detect type and attach
them accordingly.

In practice, I'm curious what I can attach programs of this type to,
and how are they specified? `bpf_program__attach()` doesn't take any
parameters outside of the program itself. Does it attach based on the
name of the program's name/section? If so, is there an idiomatic way
of making sure this is correctly done?

My follow up question is to ask how fentry/fexit relate. I've seen
these referred to as program types but in code they appear as attach
types, not program types. Can someone clarify?

As always I'm partly asking so that I can document this and avoid
other people having the same confusion :-)

Thank you very much!
Grant

Re: Questions on BPF_PROG_TYPE_TRACING & fentry/fexit

[Andrii Nakryiko]

On Fri, Apr 1, 2022 at 7:27 AM Grant Seltzer Richman
<grantseltzer@gmail.com> wrote:
>
> Hi there,
>
> I'm looking to implement programs of type BPF_PROG_TYPE_TRACING to
> replace kprobe/tracepoints because from what I can tell there's less
> performance overhead. However, I'm trying to understand restrictions
> and use cases.
>
> I see that there's a generic `bpf_program__attach()` which can be used
> to attach programs and it will attempt to auto-detect type and attach
> them accordingly.
>
> In practice, I'm curious what I can attach programs of this type to,
> and how are they specified? `bpf_program__attach()` doesn't take any
> parameters outside of the program itself. Does it attach based on the
> name of the program's name/section? If so, is there an idiomatic way
> of making sure this is correctly done?

You can specify destination either in SEC() definition:
SEC("fentry/some_kernel_func") or you can use
bpf_program__set_attach_target(...) before BPF object is loaded.

>
> My follow up question is to ask how fentry/fexit relate. I've seen
> these referred to as program types but in code they appear as attach
> types, not program types. Can someone clarify?

Formally they are different expected attach types for
BPF_PROG_TYPE_TRACING program type. There is also fmod_ret, which is
yet another expected attach type with still different semantics. But
it's like kprobe and kretprobe, they have very different semantics, so
we talk about them as two different types of BPF program.

>
> As always I'm partly asking so that I can document this and avoid
> other people having the same confusion :-)
>

Yep, I appreciate it. Please send follow up questions if you still
have some. Please check relevant selftests to see possible usages.

> Thank you very much!
> Grant

Re: Questions on BPF_PROG_TYPE_TRACING & fentry/fexit

[Grant Seltzer Richman]

On Sun, Apr 3, 2022 at 7:47 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Fri, Apr 1, 2022 at 7:27 AM Grant Seltzer Richman
> <grantseltzer@gmail.com> wrote:
> >
> > Hi there,
> >
> > I'm looking to implement programs of type BPF_PROG_TYPE_TRACING to
> > replace kprobe/tracepoints because from what I can tell there's less
> > performance overhead. However, I'm trying to understand restrictions
> > and use cases.
> >
> > I see that there's a generic `bpf_program__attach()` which can be used
> > to attach programs and it will attempt to auto-detect type and attach
> > them accordingly.
> >
> > In practice, I'm curious what I can attach programs of this type to,
> > and how are they specified? `bpf_program__attach()` doesn't take any
> > parameters outside of the program itself. Does it attach based on the
> > name of the program's name/section? If so, is there an idiomatic way
> > of making sure this is correctly done?
>
> You can specify destination either in SEC() definition:
> SEC("fentry/some_kernel_func") or you can use
> bpf_program__set_attach_target(...) before BPF object is loaded.

Can you elaborate more on `bpf_program__set_attach_target()`? I've
been working through the selftests and understand that you can use it
to attach bpf programs to other bpf programs, and kernel modules. Are
there only certain types of bpf programs that can be attached to? Are
there restrictions on what kind of programs can attach to others?

> >
> > My follow up question is to ask how fentry/fexit relate. I've seen
> > these referred to as program types but in code they appear as attach
> > types, not program types. Can someone clarify?
>
> Formally they are different expected attach types for
> BPF_PROG_TYPE_TRACING program type. There is also fmod_ret, which is
> yet another expected attach type with still different semantics. But
> it's like kprobe and kretprobe, they have very different semantics, so
> we talk about them as two different types of BPF program.
>
> >
> > As always I'm partly asking so that I can document this and avoid
> > other people having the same confusion :-)
> >
>
> Yep, I appreciate it. Please send follow up questions if you still
> have some. Please check relevant selftests to see possible usages.
>
> > Thank you very much!
> > Grant

Re: Questions on BPF_PROG_TYPE_TRACING & fentry/fexit

[Andrii Nakryiko]

On Wed, Apr 6, 2022 at 1:01 PM Grant Seltzer Richman
<grantseltzer@gmail.com> wrote:
>
> On Sun, Apr 3, 2022 at 7:47 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Fri, Apr 1, 2022 at 7:27 AM Grant Seltzer Richman
> > <grantseltzer@gmail.com> wrote:
> > >
> > > Hi there,
> > >
> > > I'm looking to implement programs of type BPF_PROG_TYPE_TRACING to
> > > replace kprobe/tracepoints because from what I can tell there's less
> > > performance overhead. However, I'm trying to understand restrictions
> > > and use cases.
> > >
> > > I see that there's a generic `bpf_program__attach()` which can be used
> > > to attach programs and it will attempt to auto-detect type and attach
> > > them accordingly.
> > >
> > > In practice, I'm curious what I can attach programs of this type to,
> > > and how are they specified? `bpf_program__attach()` doesn't take any
> > > parameters outside of the program itself. Does it attach based on the
> > > name of the program's name/section? If so, is there an idiomatic way
> > > of making sure this is correctly done?
> >
> > You can specify destination either in SEC() definition:
> > SEC("fentry/some_kernel_func") or you can use
> > bpf_program__set_attach_target(...) before BPF object is loaded.
>
> Can you elaborate more on `bpf_program__set_attach_target()`? I've
> been working through the selftests and understand that you can use it
> to attach bpf programs to other bpf programs, and kernel modules. Are
> there only certain types of bpf programs that can be attached to? Are
> there restrictions on what kind of programs can attach to others?

You can attach to kernel functions as well, if you specify
attach_prog_fd = 0. See the implementation in tools/lib/bpf/libbpf.c.
As for types of programs, it's fentry/fexit/fmod_ret and freplace for
attaching to other programs. All the details about freplace... I'm not
the best expert on that and you'll have to read kernel
code/docs/experiment.

>
> > >
> > > My follow up question is to ask how fentry/fexit relate. I've seen
> > > these referred to as program types but in code they appear as attach
> > > types, not program types. Can someone clarify?
> >
> > Formally they are different expected attach types for
> > BPF_PROG_TYPE_TRACING program type. There is also fmod_ret, which is
> > yet another expected attach type with still different semantics. But
> > it's like kprobe and kretprobe, they have very different semantics, so
> > we talk about them as two different types of BPF program.
> >
> > >
> > > As always I'm partly asking so that I can document this and avoid
> > > other people having the same confusion :-)
> > >
> >
> > Yep, I appreciate it. Please send follow up questions if you still
> > have some. Please check relevant selftests to see possible usages.
> >
> > > Thank you very much!
> > > Grant