From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Christy Lee <christylee@fb.com>,
Andrii Nakryiko <andrii@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Christy Lee <christyc.y.lee@gmail.com>, bpf <bpf@vger.kernel.org>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
Kernel Team <kernel-team@fb.com>, He Kuang <hekuang@huawei.com>,
Wang Nan <wangnan0@huawei.com>,
Wang ShaoBo <bobo.shaobowang@huawei.com>,
YueHaibing <yuehaibing@huawei.com>
Subject: Re: [PATCH bpf-next 2/2] perf: stop using deprecated bpf__object_next() API
Date: Wed, 22 Dec 2021 14:44:52 +0100 [thread overview]
Message-ID: <YcMr1LeP6zUBdCiK@krava> (raw)
In-Reply-To: <CAEf4BzZpNvEtfsVHUJGfwi_1xM+7-ohBPKPrRo--X=fYkYLrsw@mail.gmail.com>
On Tue, Dec 21, 2021 at 01:58:14PM -0800, Andrii Nakryiko wrote:
> On Tue, Dec 21, 2021 at 12:23 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Thu, Dec 16, 2021 at 02:21:08PM -0800, Christy Lee wrote:
> > > bpf__object_next is deprecated, track bpf_objects directly in
> > > perf instead.
> > >
> > > Signed-off-by: Christy Lee <christylee@fb.com>
> > > Acked-by: Andrii Nakryiko <andrii@kernel.org>
> > > ---
> > > tools/perf/util/bpf-loader.c | 72 +++++++++++++++++++++++++++---------
> > > tools/perf/util/bpf-loader.h | 1 +
> > > 2 files changed, 55 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> > > index 528aeb0ab79d..9e3988fd719a 100644
> > > --- a/tools/perf/util/bpf-loader.c
> > > +++ b/tools/perf/util/bpf-loader.c
> > > @@ -29,9 +29,6 @@
> > >
> > > #include <internal/xyarray.h>
> > >
> > > -/* temporarily disable libbpf deprecation warnings */
> > > -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > > -
> > > static int libbpf_perf_print(enum libbpf_print_level level __attribute__((unused)),
> > > const char *fmt, va_list args)
> > > {
> > > @@ -49,6 +46,36 @@ struct bpf_prog_priv {
> > > int *type_mapping;
> > > };
> > >
> > > +struct bpf_perf_object {
> > > + struct bpf_object *obj;
> > > + struct list_head list;
> > > +};
> > > +
> > > +static LIST_HEAD(bpf_objects_list);
> >
> > hum, so this duplicates libbpf's bpf_objects_list,
> > how do objects get on this list?
>
> yep, this list needs to be updated on perf side each time
> bpf_object__open() (and any variant of open) is called.
>
> >
> > could you please put more comments in changelog
> > and share how you tested this?
>
> I actually have no idea how to test this as well, can you please share
> some ideas?
>
I don't use it, I just know it's there.. that's why I asked ;-)
it's possible to specify bpf program on the perf command line
to be attached to event, like:
# cat tools/perf/examples/bpf/hello.c
#include <stdio.h>
int syscall_enter(openat)(void *args)
{
puts("Hello, world\n");
return 0;
}
license(GPL);
#
# perf trace -e openat,tools/perf/examples/bpf/hello.c cat /etc/passwd > /dev/null
0.016 ( ): __bpf_stdout__:Hello, world
0.018 ( 0.010 ms): cat/9079 openat(dfd: CWD, filename: /etc/ld.so.cache, flags: CLOEXEC) = 3
0.057 ( ): __bpf_stdout__:Hello, world
0.059 ( 0.011 ms): cat/9079 openat(dfd: CWD, filename: /lib64/libc.so.6, flags: CLOEXEC) = 3
0.417 ( ): __bpf_stdout__:Hello, world
0.419 ( 0.009 ms): cat/9079 openat(dfd: CWD, filename: /etc/passwd) = 3
#
I took that example from commit message
>
> BTW, while we are at it, Jiri, do you have any good ideas on how to
> remove perf's usage of bpf_program__set_priv() and
> bpf_program__set_prep() APIs in perf code base? These APIs are
> deprecated as well, but seems like perf relies on them pretty heavily.
> What would be the best way to stop using them?
>
> For set_priv(), I think it should be totally fine to maintain a
> separate lookup hash table by `struct bpf_program *` or its name, that
> shouldn't be hard.
ok, so there's no alternative api for this one then
>
> But for set_prep(), what does perf use it for? I assume for cloning
> BPF programs, right? Anything else besides that? If it's just for
> cloning, libbpf provides bpf_program__insns() API to get access to
> underlying bpf_insn array, do you think it's possible to switch perf
> to that instead?
look like it's used to generate prologs for programs:
a08357d8dc7d perf bpf: Generate prologue for BPF programs
the author Wang Nan haven't touched that for some time,
I'm cc-ing other folks that were involved.. Arnaldo? ;-)
if nobody volunteers, I can check on that
jirka
next prev parent reply other threads:[~2021-12-22 13:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 22:21 [PATCH bpf-next 0/2] perf: stop using deprecated bpf APIs Christy Lee
2021-12-16 22:21 ` [PATCH bpf-next 1/2] perf: stop using deprecated bpf_prog_load() API Christy Lee
2021-12-16 22:21 ` [PATCH bpf-next 2/2] perf: stop using deprecated bpf__object_next() API Christy Lee
2021-12-21 8:22 ` Jiri Olsa
2021-12-21 21:58 ` Andrii Nakryiko
2021-12-22 13:44 ` Jiri Olsa [this message]
2021-12-22 22:17 ` Andrii Nakryiko
2021-12-29 19:01 ` Christy Lee
2022-01-04 14:40 ` Jiri Olsa
2022-01-05 13:49 ` Jiri Olsa
2022-01-06 17:54 ` Christy Lee
2022-01-06 22:41 ` Jiri Olsa
2022-01-13 15:14 ` Jiri Olsa
2022-01-14 21:00 ` Andrii Nakryiko
2022-01-17 9:25 ` Jiri Olsa
2022-01-18 23:05 ` Andrii Nakryiko
2022-01-22 20:29 ` Arnaldo Carvalho de Melo
2022-01-06 20:25 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YcMr1LeP6zUBdCiK@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bobo.shaobowang@huawei.com \
--cc=bpf@vger.kernel.org \
--cc=christyc.y.lee@gmail.com \
--cc=christylee@fb.com \
--cc=hekuang@huawei.com \
--cc=kernel-team@fb.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=wangnan0@huawei.com \
--cc=yuehaibing@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.