All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	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: [PATCH perf/core 1/5] libbpf: Add bpf_program__set_insns function
Date: Tue, 26 Apr 2022 08:57:11 +0200	[thread overview]
Message-ID: <YmeXx0mfy4Nr5jEB@krava> (raw)
In-Reply-To: <CAEf4BzZOKosYRHwK2CfZzpTUcDdrLXPXbYax++Q_PHCMcNdqCw@mail.gmail.com>

On Mon, Apr 25, 2022 at 11:19:09PM -0700, Andrii Nakryiko wrote:
> On Mon, Apr 25, 2022 at 9:22 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 4/22/22 12:00 PM, Jiri Olsa wrote:
> > > Adding bpf_program__set_insns that allows to set new
> > > instructions for program.
> > >
> > > Also moving bpf_program__attach_kprobe_multi_opts on
> > > the proper name sorted place in map file.
> 
> would make sense to fix it as a separate patch, it has nothing to do
> with bpf_program__set_insns() API itself

np

> 
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > ---
> > >   tools/lib/bpf/libbpf.c   |  8 ++++++++
> > >   tools/lib/bpf/libbpf.h   | 12 ++++++++++++
> > >   tools/lib/bpf/libbpf.map |  3 ++-
> > >   3 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > index 809fe209cdcc..284790d81c1b 100644
> > > --- a/tools/lib/bpf/libbpf.c
> > > +++ b/tools/lib/bpf/libbpf.c
> > > @@ -8457,6 +8457,14 @@ size_t bpf_program__insn_cnt(const struct bpf_program *prog)
> > >       return prog->insns_cnt;
> > >   }
> > >
> > > +void bpf_program__set_insns(struct bpf_program *prog,
> > > +                         struct bpf_insn *insns, size_t insns_cnt)
> > > +{
> > > +     free(prog->insns);
> > > +     prog->insns = insns;
> > > +     prog->insns_cnt = insns_cnt;
> 
> let's not store user-provided pointer here. Please realloc prog->insns
> as necessary and copy over insns into it.
> 
> Also let's at least add the check for prog->loaded and return -EBUSY
> in such a case. And of course this API should return int, not void.

ok, will change

> 
> > > +}
> > > +
> > >   int bpf_program__set_prep(struct bpf_program *prog, int nr_instances,
> > >                         bpf_program_prep_t prep)
> > >   {
> > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > index 05dde85e19a6..b31ad58d335f 100644
> > > --- a/tools/lib/bpf/libbpf.h
> > > +++ b/tools/lib/bpf/libbpf.h
> > > @@ -323,6 +323,18 @@ struct bpf_insn;
> > >    * different.
> > >    */
> > >   LIBBPF_API const struct bpf_insn *bpf_program__insns(const struct bpf_program *prog);
> > > +
> > > +/**
> > > + * @brief **bpf_program__set_insns()** can set BPF program's underlying
> > > + * BPF instructions.
> > > + * @param prog BPF program for which to return instructions
> > > + * @param insn a pointer to an array of BPF instructions
> > > + * @param insns_cnt number of `struct bpf_insn`'s that form
> > > + * specified BPF program
> > > + */
> 
> This API makes me want to cry... but I can't come up with anything
> better for perf's use case.
> 
> But it can only more or less safely and sanely be used from the
> prog_prepare_load_fn callback, so please add a big warning here saying
> that this is a very advanced libbpf API and the user needs to know
> what they are doing and this should be used from prog_prepare_load_fn
> callback only. If bpf_program__set_insns() is called before
> prog_prepare_load_fn any map/subprog/etc relocation will most probably
> fail or corrupt BPF program code.

will add the warnings

> 
> > > +LIBBPF_API void bpf_program__set_insns(struct bpf_program *prog,
> > > +                                    struct bpf_insn *insns, size_t insns_cnt);
> 
> s/insns_cnt/insn_cnt/
> 
> > > +
> >
> > Iiuc, patch 2 should be squashed into this one given they logically belong to the
> > same change?
> >
> > Fwiw, I think the API description should be elaborated a bit more, in particular that
> > the passed-in insns need to be from allocated dynamic memory which is later on passed
> > to free(), and maybe also constraints at which point in time bpf_program__set_insns()
> > may be called.. (as well as high-level description on potential use cases e.g. around
> > patch 4).
> 
> Yep, patch #1 is kind of broken without patch #2, so let's combine them.

ok

thanks,
jirka

  reply	other threads:[~2022-04-26  6:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 10:00 [PATCH perf/core 0/5] perf tools: Fix prologue generation Jiri Olsa
2022-04-22 10:00 ` [PATCH perf/core 1/5] libbpf: Add bpf_program__set_insns function Jiri Olsa
2022-04-25 16:22   ` Daniel Borkmann
2022-04-26  6:19     ` Jiri Olsa
2022-04-26  6:19     ` Andrii Nakryiko
2022-04-26  6:57       ` Jiri Olsa [this message]
2022-04-26 15:58         ` Andrii Nakryiko
2022-04-27  8:42           ` Jiri Olsa
2022-04-27 18:47             ` Andrii Nakryiko
2022-04-22 10:00 ` [PATCH perf/core 2/5] libbpf: Load prog's instructions after prog_prepare_load_fn callback Jiri Olsa
2022-04-22 10:00 ` [PATCH perf/core 3/5] perf tools: Move libbpf init in libbpf_init function Jiri Olsa
2022-04-22 17:03   ` Arnaldo Carvalho de Melo
2022-04-25  7:25     ` Jiri Olsa
2022-04-26  6:21       ` Andrii Nakryiko
2022-04-22 10:00 ` [PATCH perf/core 4/5] perf tools: Register perfkprobe libbpf section handler Jiri Olsa
2022-04-26  6:22   ` Andrii Nakryiko
2022-04-26  6:58     ` Jiri Olsa
2022-04-22 10:00 ` [PATCH perf/core 5/5] perf tools: Rework prologue generation code 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=YmeXx0mfy4Nr5jEB@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 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.