All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: 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: Tue, 10 May 2022 16:45:01 -0700	[thread overview]
Message-ID: <CAEf4Bzav8he-_fD=D5KMFW7s=PkJoZG9cUr+BOTuV54KKOC70A@mail.gmail.com> (raw)
In-Reply-To: <20220510074659.2557731-3-jolsa@kernel.org>

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?

> +       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
>

  reply	other threads:[~2022-05-10 23:45 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 [this message]
2022-05-11  7:36     ` Jiri Olsa
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='CAEf4Bzav8he-_fD=D5KMFW7s=PkJoZG9cUr+BOTuV54KKOC70A@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.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 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.