[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzaGLRYiQtT4_HV1ntAV0Br2yyRo5sZiebVAt9QJ8WVF5g@mail.gmail.com>
Date: Mon, 25 Apr 2022 23:22:54 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
"linux-perf-use." <linux-perf-users@...r.kernel.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
Ian Rogers <irogers@...gle.com>
Subject: Re: [PATCH perf/core 4/5] perf tools: Register perfkprobe libbpf
section handler
On Fri, Apr 22, 2022 at 3:01 AM Jiri Olsa <jolsa@...nel.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 support for 'perfkprobe/' section name handler to take
> care of perf kprobe programs.
>
> The handler servers 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@...nel.org>
> ---
> tools/perf/util/bpf-loader.c | 50 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> index f8ad581ea247..92dd8cc18edb 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,61 @@ 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),
> + 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),
> +};
> +
> +#define LIBBPF_SEC_PREFIX "perfkprobe/"
libbpf allows to register fallback handler that will handle any SEC()
definition besides the ones that libbpf handles. Would that work in
this case instead of adding a custom prefix handler here? See
prog_tests/custom_sec_handlers.c for example:
fallback_id = libbpf_register_prog_handler(NULL,
BPF_PROG_TYPE_SYSCALL, 0, &opts);
> +
[...]
Powered by blists - more mailing lists