[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzY4RaB5n1k7-O5XtCAOc9Rq=sYS1zLt_mDLih=4ypvb7g@mail.gmail.com>
Date: Tue, 15 Jul 2025 10:23:57 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Menglong Dong <menglong.dong@...ux.dev>
Cc: Menglong Dong <menglong8.dong@...il.com>, alexei.starovoitov@...il.com,
rostedt@...dmis.org, jolsa@...nel.org, bpf@...r.kernel.org,
Menglong Dong <dongml2@...natelecom.cn>, Martin KaFai Lau <martin.lau@...ux.dev>,
Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 15/18] libbpf: add skip_invalid and
attach_tracing for tracing_multi
On Mon, Jul 14, 2025 at 10:49 PM Menglong Dong <menglong.dong@...ux.dev> wrote:
>
>
> On 7/15/25 06:07, Andrii Nakryiko wrote:
> > On Thu, Jul 3, 2025 at 5:23 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> >> We add skip_invalid and attach_tracing for tracing_multi for the
> >> selftests.
> >>
> >> When we try to attach all the functions in available_filter_functions with
> >> tracing_multi, we can't tell if the target symbol can be attached
> >> successfully, and the attaching will fail. When skip_invalid is set to
> >> true, we will check if it can be attached in libbpf, and skip the invalid
> >> entries.
> >>
> >> We will skip the symbols in the following cases:
> >>
> >> 1. the btf type not exist
> >> 2. the btf type is not a function proto
> >> 3. the function args count more that 6
> >> 4. the return type is struct or union
> >> 5. any function args is struct or union
> >>
> >> The 5th rule can be a manslaughter, but it's ok for the testings.
> >>
> >> "attach_tracing" is used to convert a TRACING prog to TRACING_MULTI. For
> >> example, we can set the attach type to FENTRY_MULTI before we load the
> >> skel. And we can attach the prog with
> >> bpf_program__attach_trace_multi_opts() with "attach_tracing=1". The libbpf
> >> will attach the target btf type of the prog automatically. This is also
> >> used to reuse the selftests of tracing.
> >>
> >> (Oh my goodness! What am I doing?)
> > exactly...
> >
> > Let's think if we need any of that, as in: take a step back, and try
> > to explain why you think any of this should be part of libbpf's UAPI.
>
> I know it's weird. The "attach_tracing" is used for selftests, which I can
> use something else instead. But the "skip_invalid" is something that we
> need.
>
> For example, we have a function list, which contains 1000 kernel functions,
> and we want to attach fentry-multi to them. However, we don't know which
> of them can't be attached, so the attachment will fail. And we need a way to
> skip the functions that can't be attached to make the attachment success.
The right answer here is you need to know what's attachable and what's
not, instead of just ignoring attachment failures somewhere deep
inside libbpf API. Filter and check before you try to attach. There is
/sys/kernel/tracing/available_filter_functions and some similar
blacklist file, consult that, filter out stuff that's not attachable.
We won't be adding libbpf APIs just to make some selftests easier to
write by being sloppy.
>
> This should be a common use case. And let me do more research to see if
> we can do such filter out of the libbpf.
I have similar issues with retsnoop ([0]) and do just fine without
abusing libbpf API.
[0] https://github.com/anakryiko/retsnoop/blob/master/src/mass_attacher.c#L749
>
> Thanks!
> Menglong Dong
>
>
> >
> >> Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>
> >> ---
> >> tools/lib/bpf/libbpf.c | 97 ++++++++++++++++++++++++++++++++++++------
> >> tools/lib/bpf/libbpf.h | 6 ++-
> >> 2 files changed, 89 insertions(+), 14 deletions(-)
> >>
> > [...]
> >
Powered by blists - more mailing lists