From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
Ian Rogers <irogers@google.com>
Subject: Re: [PATCHv2 perf/core 2/3] perf tools: Register fallback libbpf section handler
Date: Wed, 11 May 2022 09:36:12 +0200 [thread overview]
Message-ID: <YntnbEzE1LeIKXk4@krava> (raw)
In-Reply-To: <CAEf4Bzav8he-_fD=D5KMFW7s=PkJoZG9cUr+BOTuV54KKOC70A@mail.gmail.com>
On Tue, May 10, 2022 at 04:45:01PM -0700, Andrii Nakryiko wrote:
> On Tue, May 10, 2022 at 12:47 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Perf is using section name to declare special kprobe arguments,
> > which no longer works with current libbpf, that either requires
> > certain form of the section name or allows to register custom
> > handler.
> >
> > Adding perf support to register 'fallback' section handler to take
> > care of perf kprobe programs. The fallback means that it handles
> > any section definition besides the ones that libbpf handles.
> >
> > The handler serves two purposes:
> > - allows perf programs to have special arguments in section name
> > - allows perf to use pre-load callback where we can attach init
> > code (zeroing all argument registers) to each perf program
> >
> > The second is essential part of new prologue generation code,
> > that's coming in following patch.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > tools/perf/util/bpf-loader.c | 47 ++++++++++++++++++++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> > index f8ad581ea247..2a2c9512c4e8 100644
> > --- a/tools/perf/util/bpf-loader.c
> > +++ b/tools/perf/util/bpf-loader.c
> > @@ -86,6 +86,7 @@ bpf_perf_object__next(struct bpf_perf_object *prev)
> > (perf_obj) = (tmp), (tmp) = bpf_perf_object__next(tmp))
> >
> > static bool libbpf_initialized;
> > +static int libbpf_sec_handler;
> >
> > static int bpf_perf_object__add(struct bpf_object *obj)
> > {
> > @@ -99,12 +100,58 @@ static int bpf_perf_object__add(struct bpf_object *obj)
> > return perf_obj ? 0 : -ENOMEM;
> > }
> >
> > +static struct bpf_insn prologue_init_insn[] = {
> > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > + BPF_MOV64_IMM(BPF_REG_1, 0),
>
> R0 should be initialized before exit anyway. R1 contains context, so
> doesn't need initialization, so I think you only need R2-R5?
ah right, I'll remove that
thanks,
jirka
>
> > + BPF_MOV64_IMM(BPF_REG_2, 0),
> > + BPF_MOV64_IMM(BPF_REG_3, 0),
> > + BPF_MOV64_IMM(BPF_REG_4, 0),
> > + BPF_MOV64_IMM(BPF_REG_5, 0),
> > +};
> > +
> > +static int libbpf_prog_prepare_load_fn(struct bpf_program *prog,
> > + struct bpf_prog_load_opts *opts __maybe_unused,
> > + long cookie __maybe_unused)
> > +{
> > + size_t init_size_cnt = ARRAY_SIZE(prologue_init_insn);
> > + size_t orig_insn_cnt, insn_cnt, init_size, orig_size;
> > + const struct bpf_insn *orig_insn;
> > + struct bpf_insn *insn;
> > +
> > + /* prepend initialization code to program instructions */
> > + orig_insn = bpf_program__insns(prog);
> > + orig_insn_cnt = bpf_program__insn_cnt(prog);
> > + init_size = init_size_cnt * sizeof(*insn);
> > + orig_size = orig_insn_cnt * sizeof(*insn);
> > +
> > + insn_cnt = orig_insn_cnt + init_size_cnt;
> > + insn = malloc(insn_cnt * sizeof(*insn));
> > + if (!insn)
> > + return -ENOMEM;
> > +
> > + memcpy(insn, prologue_init_insn, init_size);
> > + memcpy((char *) insn + init_size, orig_insn, orig_size);
> > + bpf_program__set_insns(prog, insn, insn_cnt);
> > + return 0;
> > +}
> > +
> > static int libbpf_init(void)
> > {
> > + LIBBPF_OPTS(libbpf_prog_handler_opts, handler_opts,
> > + .prog_prepare_load_fn = libbpf_prog_prepare_load_fn,
> > + );
> > +
> > if (libbpf_initialized)
> > return 0;
> >
> > libbpf_set_print(libbpf_perf_print);
> > + libbpf_sec_handler = libbpf_register_prog_handler(NULL, BPF_PROG_TYPE_KPROBE,
> > + 0, &handler_opts);
> > + if (libbpf_sec_handler < 0) {
> > + pr_debug("bpf: failed to register libbpf section handler: %d\n",
> > + libbpf_sec_handler);
> > + return -BPF_LOADER_ERRNO__INTERNAL;
> > + }
> > libbpf_initialized = true;
> > return 0;
> > }
> > --
> > 2.35.3
> >
next prev parent reply other threads:[~2022-05-11 7:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 7:46 [PATCHv2 0/3] perf tools: Fix prologue generation Jiri Olsa
2022-05-10 7:46 ` [PATCHv2 bpf-next 1/3] libbpf: Add bpf_program__set_insns function Jiri Olsa
2022-05-10 7:46 ` [PATCHv2 perf/core 2/3] perf tools: Register fallback libbpf section handler Jiri Olsa
2022-05-10 23:45 ` Andrii Nakryiko
2022-05-11 7:36 ` Jiri Olsa [this message]
2022-05-10 7:46 ` [PATCHv2 perf/core 3/3] perf tools: Rework prologue generation code Jiri Olsa
2022-05-10 23:48 ` [PATCHv2 0/3] perf tools: Fix prologue generation Andrii Nakryiko
2022-05-11 7:35 ` Jiri Olsa
2022-05-11 18:22 ` Arnaldo Carvalho de Melo
2022-05-17 22:02 ` Andrii Nakryiko
2022-05-18 4:45 ` Ian Rogers
2022-05-18 9:48 ` Jiri Olsa
2022-05-18 9:46 ` Jiri Olsa
2022-05-19 11:03 ` Jiri Olsa
2022-05-20 21:46 ` Andrii Nakryiko
2022-05-21 17:44 ` Arnaldo Carvalho de Melo
2022-05-23 7:49 ` Jiri Olsa
2022-05-23 22:43 ` Andrii Nakryiko
2022-05-24 8:28 ` Jiri Olsa
2022-06-01 17:39 ` Andrii Nakryiko
2022-06-01 18:09 ` Jiri Olsa
2022-05-11 12:20 ` patchwork-bot+netdevbpf
2022-05-27 1:16 ` Arnaldo Carvalho de Melo
2022-06-01 18:11 ` Jiri Olsa
2022-06-01 22:21 ` Andrii Nakryiko
2022-06-02 10:08 ` Jiri Olsa
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=YntnbEzE1LeIKXk4@krava \
--to=olsajiri@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=irogers@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox