[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3937006.kQq0lBPeGt@7940hx>
Date: Wed, 16 Jul 2025 19:46:05 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Menglong Dong <menglong8.dong@...il.com>, alexei.starovoitov@...il.com,
rostedt@...dmis.org, jolsa@...nel.org, bpf@...r.kernel.org,
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 Wednesday, July 16, 2025 1:23 AM Andrii Nakryiko <andrii.nakryiko@...il.com> write:
[......]
>
> 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
Thank you for the reference, and I think it will work to do such
filtering in the selftests.
Powered by blists - more mailing lists