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>,
Andrii Nakryiko <andrii@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ian Rogers <irogers@google.com>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH 3/3] perf tools: Rework prologue generation code
Date: Fri, 18 Feb 2022 10:01:45 +0100 [thread overview]
Message-ID: <Yg9geQ0LJjhnrc7j@krava> (raw)
In-Reply-To: <CAEf4BzYP7=JuyuY=xZe71urpxat4ba-JnqeSTcHF=CYmsQbofQ@mail.gmail.com>
On Thu, Feb 17, 2022 at 01:53:16PM -0800, Andrii Nakryiko wrote:
> On Thu, Feb 17, 2022 at 5:19 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Some functions we use now for bpf prologue generation are
> > going to be deprecated, so reworking the current code not
> > to use them.
> >
> > We need to replace following functions/struct:
> > bpf_program__set_prep
> > bpf_program__nth_fd
> > struct bpf_prog_prep_result
> >
> > Current code uses bpf_program__set_prep to hook perf callback
> > before the program is loaded and provide new instructions with
> > the prologue.
> >
> > We workaround this by using objects's 'unloaded' programs instructions
> > for that specific program and load new ebpf programs with prologue
> > using separate bpf_prog_load calls.
> >
> > We keep new ebpf program instances descriptors in bpf programs
> > private struct.
> >
> > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > tools/perf/util/bpf-loader.c | 122 +++++++++++++++++++++++++++++------
> > 1 file changed, 104 insertions(+), 18 deletions(-)
> >
>
> [...]
>
> > errout:
> > @@ -696,7 +718,7 @@ static int hook_load_preprocessor(struct bpf_program *prog)
> > struct bpf_prog_priv *priv = program_priv(prog);
> > struct perf_probe_event *pev;
> > bool need_prologue = false;
> > - int err, i;
> > + int i;
> >
> > if (IS_ERR_OR_NULL(priv)) {
> > pr_debug("Internal error when hook preprocessor\n");
> > @@ -727,6 +749,12 @@ static int hook_load_preprocessor(struct bpf_program *prog)
> > return 0;
> > }
> >
> > + /*
> > + * Do not load programs that need prologue, because we need
> > + * to add prologue first, check bpf_object__load_prologue.
> > + */
> > + bpf_program__set_autoload(prog, false);
>
> if you set autoload to false, program instructions might be invalid in
> the end. Libbpf doesn't apply some (all?) relocations to such
> programs, doesn't resolve CO-RE, etc, etc. You have to let
> "prototypal" BPF program to be loaded before you can grab final
> instructions. It's not great, but in your case it should work, right?
hum, do we care? it should all be done when the 'new' program with
the prologue is loaded, right?
I switched it off because the verifier failed to load the program
without the prologue.. because in the originaal program there's no
code to grab the arguments that the rest of the code depends on,
so the verifier sees invalid access
>
> > +
> > priv->need_prologue = true;
> > priv->insns_buf = malloc(sizeof(struct bpf_insn) * BPF_MAXINSNS);
> > if (!priv->insns_buf) {
> > @@ -734,6 +762,13 @@ static int hook_load_preprocessor(struct bpf_program *prog)
> > return -ENOMEM;
> > }
> >
>
> [...]
>
> > + /*
> > + * For each program that needs prologue we do following:
> > + *
> > + * - take its current instructions and use them
> > + * to generate the new code with prologue
> > + *
> > + * - load new instructions with bpf_prog_load
> > + * and keep the fd in proglogue_fds
> > + *
> > + * - new fd will be used bpf__foreach_event
> > + * to connect this program with perf evsel
> > + */
> > + orig_insns = bpf_program__insns(prog);
> > + orig_insns_cnt = bpf_program__insn_cnt(prog);
> > +
> > + pev = &priv->pev;
> > + for (i = 0; i < pev->ntevs; i++) {
> > + err = preproc_gen_prologue(prog, i, orig_insns,
> > + orig_insns_cnt, &res);
> > + if (err)
> > + return err;
> > +
> > + fd = bpf_prog_load(bpf_program__get_type(prog),
>
> nit: bpf_program__type() is preferred (we are deprecating/discouraging
> "get_" prefixed getters in libbpf 1.0)
ok, will change
>
> > + bpf_program__name(prog), "GPL",
>
> would it make sense to give each clone a distinct name?
AFAICS the original code uses same prog name for instances,
so I'd rather keep it that way
thanks,
jirka
>
> > + res.new_insn_ptr,
> > + res.new_insn_cnt, NULL);
> > + if (fd < 0) {
> > + char bf[128];
> > +
>
> [...]
next prev parent reply other threads:[~2022-02-18 9:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 13:19 [PATCHv2 0/3] perf/bpf: Replace deprecated code Jiri Olsa
2022-02-17 13:19 ` [PATCH 1/3] perf tools: Remove bpf_program__set_priv/bpf_program__priv usage Jiri Olsa
2022-02-17 21:47 ` Andrii Nakryiko
2022-02-18 9:01 ` Jiri Olsa
2022-02-17 13:19 ` [PATCH 2/3] perf tools: Remove bpf_map__set_priv/bpf_map__priv usage Jiri Olsa
2022-02-17 21:49 ` Andrii Nakryiko
2022-02-18 9:01 ` Jiri Olsa
2022-02-17 13:19 ` [PATCH 3/3] perf tools: Rework prologue generation code Jiri Olsa
2022-02-17 21:53 ` Andrii Nakryiko
2022-02-18 9:01 ` Jiri Olsa [this message]
2022-02-18 13:03 ` Jiri Olsa
2022-02-18 14:22 ` Jiri Olsa
2022-02-18 19:55 ` Andrii Nakryiko
2022-02-20 13:44 ` Jiri Olsa
[not found] ` <aa29a73b-b40d-6adf-2252-308917603f05@fb.com>
2022-02-20 23:10 ` Jiri Olsa
2022-02-23 22:29 ` Andrii Nakryiko
2022-02-25 12:14 ` Jiri Olsa
2022-02-25 14:32 ` Arnaldo Carvalho de Melo
2022-02-17 21:55 ` [PATCHv2 0/3] perf/bpf: Replace deprecated code Andrii Nakryiko
2022-02-18 9:01 ` 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=Yg9geQ0LJjhnrc7j@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=bpf@vger.kernel.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).